SHOW TABLES
in [PgSql]
|
From: "Kevin Grittner" on 15 Jul 2010 12:55 Simon Riggs <simon(a)2ndQuadrant.com> wrote: >> 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. I don't think a mess is OK regardless of who makes it. I think it would be wise to try to get some sort of consensus on what it would look like, rough as that process is. -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: Jesper Krogh on 15 Jul 2010 12:57 On 2010-07-15 18:07, Marc G. Fournier 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 ... Moving it into the backend (together with the other commands) would also solve this usabillity issue: WARNING: You are connected to a server with major version 8.4, but your psql client is major version 8.3. Some backslash commands, such as \d, might not work properly. testdb \d testtable ERROR: column "reltriggers" does not exist LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr... -- ^ Jesper
From: Simon Riggs on 15 Jul 2010 12:59 On Thu, 2010-07-15 at 18:43 +0200, 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? I imagined that we would do something similar to EXPLAIN, a set of text rows returned. It should be possible to migrate \d options to using new outputs, when everything works in a useful manner. Probably not in this release. If I get some working solutions ready for Sept 15 we then have 4 months for other people to patch away at 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: Magnus Hagander on 15 Jul 2010 13:02 On Thu, Jul 15, 2010 at 18:59, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-07-15 at 18:43 +0200, 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? > > I imagined that we would do something similar to EXPLAIN, a set of text > rows returned. Wouldn't that be useless for the case when an app wants to use it? An app will require it to be structured somehow. There's a reason we made EXPLAIN output data structured now. But I guess you could define an XML/JSON schema and return it in that... -- �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 13:16
On Thu, 2010-07-15 at 11:55 -0500, Kevin Grittner wrote: > Simon Riggs <simon(a)2ndQuadrant.com> wrote: > > >> 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. > > I don't think a mess is OK regardless of who makes it. I think it > would be wise to try to get some sort of consensus on what it would > look like, rough as that process is. So starting a discussion thread is the wrong way to achieve that? How would you have me gain consensus if not this way? -- 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 |