SHOW TABLES
in [PgSql]
|
From: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= on 15 Jul 2010 12:40 On Jul 15, 2010, at 6:20 PM, Thom Brown wrote: > On 15 July 2010 17:16, Marc G. Fournier <scrappy(a)hub.org> wrote: >> On Thu, 15 Jul 2010, Thom Brown wrote: >> >>> On 15 July 2010 17:07, Marc G. Fournier <scrappy(a)hub.org> wrote: >>>> >>>> On Thu, 15 Jul 2010, Thom Brown wrote: >>>> >>>>> If it's only a psql problem, why implement it as SQL? Is it just so >>>>> we're >>>>> not adding keywords specifically to psql? In that case, it shouldn't >>>>> support QUIT. >>>> >>>> Personally, I think this is somethign that should go into the backend ... >>>> I'd like to be able to write perl scripts that talk to the backend >>>> without >>>> having to remember all the various system tables I need to query / join >>>> to >>>> get the same results as \d gives me in psql ... same for any interface >>>> language, really ... >>>> >>> >>> Isn't that what the information_schema catalog is for? >> >> I'd rather write: >> >> SHOW TABLES; >> >> then: >> >> SELECT table_name >> FROM information_schema.tables >> WHERE table_type = 'BASE TABLE' >> AND table_schema NOT IN >> ('pg_catalog', 'information_schema'); >> >> And, the latter, unless I'm doing it regularly, is alot harder to remember >> then the former ... > > Yes, I see what you mean now. That would simplify things greatly. > > Thom > exactly ... and also: how many people outside the "inner circle" do you know who have ever seen the information schema? i have been in postgres business for more than 10 years (full time) and i cannot name 5 customers who ever used the information schema to do "show tables" ... a big argument is: "show tables" (or whatever) could work for all versions to come while a direct hit on the pg_class or so would not give you total portability forever. and yes, it is all about simplicity ... it would not even add too much code to the backend and thus the complexity of this feature can really be neglected from a maintenance point of view. regards, hans -- Cybertec Sch�nig & Sch�nig GmbH Gr�hrm�hlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 15 Jul 2010 12:43 On Thu, Jul 15, 2010 at 18:35, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > >> Is there an actual common use-case for having these commands available >> for *non-psql* interfaces? > > There are many interfaces out there and people writing new ones > everyday. We just wrote an interface for Android, for example. > > It is arguably *more* important to do this from non-psql interfaces. > > There should be one command to "display a list of tables" and it needs > to be easily guessable for those who have forgotten. The downside is that you are then limited to what can be returned as a resultset. A "\d table" in psql returns a hell of a lot more than that. So do we keep two separate formats for this? Or do we remove the current, useful, output format in favor of a much worse formt just to support more clients? -- �Magnus Hagander �Me: http://www.hagander.net/ �Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 15 Jul 2010 12:42 On Thu, 2010-07-15 at 13:16 -0300, Marc G. Fournier wrote: > I'd rather write: > > SHOW TABLES; > > then: > > SELECT table_name > FROM information_schema.tables > WHERE table_type = 'BASE TABLE' > AND table_schema NOT IN > ('pg_catalog', 'information_schema'); > > And, the latter, unless I'm doing it regularly, is alot harder to remember > then the former ... +1 -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 15 Jul 2010 12:48 On Thu, 2010-07-15 at 11:10 -0500, Robert Haas wrote: > Damn straight. I like \d as well as anyone but there are real > problems with it. Perhaps when we add \dxrvbfqS$: we'll stop to > reflect on what they are. > > Having said that, I want to urge that we spend a suitable amount of > time and thought and care designing this, lest it turn into a mess. I > have no interest in slamming something through without adequate > consideration. It's OK, I wasn't asking you or anyone else to do this. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 15 Jul 2010 12:51
Magnus Hagander <magnus(a)hagander.net> wrote: > The downside is that you are then limited to what can be returned > as a resultset. A "\d table" in psql returns a hell of a lot more > than that. So do we keep two separate formats for this? Or do we > remove the current, useful, output format in favor of a much worse > formt just to support more clients? The solution to this on some products (e.g., Sybase ASE) is to embed such logic in stored procedures. A stored procedure can generate an intermingled stream of results sets with different layouts and INFO, WARN, etc. lines. If we *had* stored procedures with such capabilities, I think that would be the direction to go; since we don't, I'm ambivalent. I don't suppose a stored procedure implementation is in the works anywhere? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |