From: "Joshua D. Drake" on 15 Jul 2010 12:05 On Thu, 2010-07-15 at 18:02 +0200, Guillaume Lelarge wrote: > > I have to agree with Simon here. \d is ridiculous for the common user. > > > > SHOW TABLES, SHOW COLUMNS makes a lot of sense. Just has something like > > DESCRIBE TABLE foo makes a lot more sense than \d. > > > > And would you add the complete syntax? I mean: > > SHOW [OPEN] TABLES [FROM db_name] [LIKE 'pattern'] > > I'm wondering what one can do with the [FROM db_name] clause :) Well I hadn't thought it out fully. I was just shutting down somebody elses idea that the feature had no legs. Which is obviously, not true. Let the discussion bloom :D JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering -- 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 12:07 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 ... ---- 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: Thom Brown on 15 Jul 2010 12:09 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? Thom -- 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: Robert Haas on 15 Jul 2010 12:10 On Jul 15, 2010, at 10:50 AM, "Joshua D. Drake" <jd(a)commandprompt.com> wrote: > On Thu, 2010-07-15 at 17:38 +0200, Magnus Hagander wrote: > >>> Looks like the last time this was discussed, there wasn't any clear >>> conclusion. Someone created a patch and it's still on the TODO list: >>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php >> >> That one is about: >> a) doing it in psql., not the backend >> b) not actually implementing the command, but implementing hints for >> the user telling them which is the correct command >> >> Is there an actual common use-case for having these commands available >> for *non-psql* interfaces? > > Yes. We should provide a single, well described grammar for interacting > with objects in the database regardless of client. I should be able to > open ANY SQL terminal, and type SHOW ME THE MONEY and have Benjamins > fall out. 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. ....Robert -- 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 12:16
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 ... ---- 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 |