SHOW TABLES
in [PgSql]
|
From: "Kevin Grittner" on 15 Jul 2010 13:36 "Joshua D. Drake" <jd(a)commandprompt.com> wrote: > I think you guys are talking past each other. So it would appear. I was replying to a comment by Simon which sounded to me as though he didn't feel any further discussion was needed. > I believe Kevin was in fact stating that we needed to continue > discussion. Right, and judging from Simon's reply, we have no disagreement on that. Sorry for the confusion. I still think that the ability to issue one request and get back a series of responses, each of which could be the result of RAISE or a SELECT, would be valuable, and would be the best way to implement this; but of course it would be totally insane to try to burden Simon's proposal with such a requirement. I was hoping that someone had something in the works, close to fruition, which could be set as a prerequisite for Simon's feature -- so that it could be done in the best possible manner. The current alternatives of a separate request for each related bit of information versus a bunch of text lines makes me a bit queasy. Formated text (XML, YAML, etc.) seems worse than either of the above. -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
From: "Marc G. Fournier" on 15 Jul 2010 13:54 On Thu, 15 Jul 2010, Magnus Hagander wrote: > 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? One is an interface comamnd (ie. psql specific), the other is a generic command for any interface ... \d doesn't work in perl or tcl or ... so, for those, we're talking about adding a 'short form' (show tables), but if someone wants to use the long form of querying multiple table s(or information_schema), that option is still open to them ... ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy(a)hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy(a)hub.org -- 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 13:57 On Thu, 2010-07-15 at 12:36 -0500, Kevin Grittner wrote: > I still think that the ability to issue one request and get back a > series of responses, each of which could be the result of RAISE or a > SELECT, would be valuable, and would be the best way to implement > this; but of course it would be totally insane to try to burden > Simon's proposal with such a requirement. I was hoping that someone > had something in the works, close to fruition, which could be set as > a prerequisite for Simon's feature -- so that it could be done in > the best possible manner. The current alternatives of a separate > request for each related bit of information versus a bunch of text > lines makes me a bit queasy. Formated text (XML, YAML, etc.) seems > worse than either of the above. Yes, the feature is harder than it first appears, but that's a reasonable reason for me to do it. But once we have the structures in place, rattling out a few patches should be easy enough. The bulk of the code could be very similar to psql and text EXPLAIN. So I would work on SHOW TABLES first, developing the core facilities required. Will come back with a full plan for discussion probably a month from now. -- 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: "Greg Sabino Mullane" on 15 Jul 2010 13:58 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > 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 ... Perl, eh? Most (all?) interfaces already have their own methods, e.g. $dbh->tables(); Of course, they don't really provide all the information that \d does, but you shouldn't need to be querying the system catalogs directly for *any* interface, including psql (for most common tasks). - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007151357 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkw/TBkACgkQvJuQZxSWSshuvACgtVpCav5qcl3nYsrsRdZ0vcT7 siUAoJaKkQ/RMAHcKCKJEyecjeEUhiQz =2mS9 -----END PGP SIGNATURE----- -- 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: Peter Eisentraut on 15 Jul 2010 14:21
On tor, 2010-07-15 at 17:35 +0100, Simon Riggs wrote: > There should be one command to "display a list of tables" and it needs > to be easily guessable for those who have forgotten. Well, if you put information_schema in the default path, it'd be SELECT * FROM TABLES; -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |