SHOW TABLES
in [PgSql]
|
From: Simon Riggs on 15 Jul 2010 17:44 On Thu, 2010-07-15 at 13:44 -0500, Robert Haas wrote: > That seems rather wretched for machine-parsability, which I think is > an important property for anything we do in this area. I completely disagree. This is for humans only, and mostly newbies only. Anybody that wants structured output can type the SQL and get as much structure as they want. I'm not reinventing the whole wheel. -- 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 17:46 On Thu, 2010-07-15 at 15:52 -0400, Andrew Dunstan wrote: > This could presumably be implemented by creating a view to return the > required information and then making "SHOW TABLES" an alias for > "select > * from viewname". > > FYI, MS-SQL does this stuff with some stored procedures. I regularly > use > sp_columns to fiind out what I'm really being asked to interact with. > See <http://msdn.microsoft.com/en-us/library/ms182764.aspx> Sounds good. OK, how about this: We write a function to derive the output, which can be executed as a function if people like that. We then make SHOW TABLEs a synonym for SELECT * FROM show_function() That way we get both in one go. -- 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: Dimitri Fontaine on 15 Jul 2010 17:59 Le 15 juil. 2010 à 18:43, Magnus Hagander <magnus(a)hagander.net> a écrit : > 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 think we should keep both, and optionaly have a given psql \d command issue more than one SHOW query. Same as it does now with SELECT queries. That means we keep a resultset per SHOW query, so it's easy on the application. Regards, -- dim -- 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: David Fetter on 15 Jul 2010 19:19 On Thu, Jul 15, 2010 at 02:31:10PM -0400, Alvaro Herrera wrote: > Excerpts from Peter Eisentraut's message of jue jul 15 14:21:26 -0400 2010: > > 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; > > Or even > > TABLE TABLES; > > weird though that is ... "Weird though that is," is *exactly* the problem we're trying to address here. SHOW TABLES is really, really easy to remember or guess. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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: Alvaro Herrera on 15 Jul 2010 20:37
Excerpts from David Fetter's message of jue jul 15 19:19:47 -0400 2010: > On Thu, Jul 15, 2010 at 02:31:10PM -0400, Alvaro Herrera wrote: > > Or even > > > > TABLE TABLES; > > > > weird though that is ... > > "Weird though that is," is *exactly* the problem we're trying to > address here. SHOW TABLES is really, really easy to remember or > guess. Eh? I thought the problem being solved is that the command is implemented in the client side rather than the server side, so all interfaces need to implement it time and time again. With TABLE TABLES there's no such problem. TABLE has also the advantage (over SHOW) that it already works on 8.4, and moreover it is SQL standard. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |