Re: SHOW TABLES - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: SHOW TABLES
Date
Msg-id 71383B90-070C-4E56-A78C-3BBCCAC0108B@hi-media.com
Whole thread Raw
In response to Re: SHOW TABLES  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
Le 16 juil. 2010 à 18:42, Kevin Grittner a écrit :
> Like \d, these server-side stored procedures can return a number of
> result sets.  Like Robert, I'm skeptical of implementing a
> server-side solution for PostgreSQL which doesn't do the same.  I'm
> not clear on whether that's even possible without a new version of
> wire protocol, though.

Well, I think we shouldn't mix it all. My view on that is that we need some easy simple commands in the backend, none
ofthem on its own would mimic \d. 

Consider this psql command: psql -E -c '\d'. What I think is that each query you see there could easily become a SHOW
subsyntax(from memory, we probably would have SHOW TABLE, SHOW INDEXES ON <table>, SHOW TRIGGERS ON <table>, SHOW
CONSTRAINTSON <table>, etc). 

Now, psql would be free to implement its \d in terms of those new queries rather than the full SQL ones it has now,
thatwould be a good first client. Oh and that means the design is about all done already. And that we still are in the
onecommand - one resultset interface. Meaning any libpq driver knows how to deal with the resultset, and that's not
parsingtext. 

I'm all with Simon here, it's not about offering any new capability that we don't already have, it's about having it
handyfrom anywhere. So let's just have an easy syntax in the backend to do all the catalog 'magic' querying psql does,
butone query at a time. 

Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte







pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: log files and permissions
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock