SHOW TABLES
in [PgSql]
|
From: "Joshua D. Drake" on 15 Jul 2010 13:17 On Thu, 2010-07-15 at 18:16 +0100, Simon Riggs wrote: > 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? I think you guys are talking past each other. I believe Kevin was in fact stating that we needed to continue discussion. Joshua D. Drake > > -- > Simon Riggs www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Training and Services > > -- 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: Simon Riggs on 15 Jul 2010 13:18 On Thu, 2010-07-15 at 19:02 +0200, Magnus Hagander wrote: > > 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... The proposed goal is simplicity, not to be all things to all men. Anybody that wants structured output can i) write that as a future patch ii) write SQL to retrieve exactly what they want (preferred) -- 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: "Andreas 'ads' Scherbaum" on 15 Jul 2010 13:21 On Thu, 15 Jul 2010 17:09:32 +0100 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? Is there a way to query all databases from information_schema? Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- 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:23 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > The solution to this on some products (e.g., Sybase ASE) is to embed > such logic in stored procedures. > ...(skip other ideas)... > > I don't suppose a stored procedure implementation is in the works > anywhere? Certainly some set-returning functions would be easy to implement, and could even be bolted on to existing systems for testing, etc. Now that plpgsql is installed by default, this is not the show-stopper it once was.... - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201007151321 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkw/Q+gACgkQvJuQZxSWSsiLpgCfU7Zt3ZmJwK0PrzYr5T0y6blD IiwAoNGoPXvxDhCbHn0MNKwxwh49fcdY =kfX8 -----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: "Greg Sabino Mullane" on 15 Jul 2010 13:26
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Moving it into the backend (together with the other commands) would > also solve this usabillity issue: .... > testdb \d testtable > ERROR: column "reltriggers" does not exist > LINE 1: SELECT relhasindex, relkind, relchecks, reltriggers, relhasr... This has already been solved at the psql level in recent versions of psql. Although, having a common functionality was always one of the proposed solutions to the problem, rather than having all the code paths inside of psql. - -- Greg Sabino Mullane greg(a)turnstep.com PGP Key: 0x14964AC8 201007151325 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkw/RMkACgkQvJuQZxSWSsglegCfU0qWorYc3c0Nq9+2weDu6dPi 3lgAn0r5w2Xbvbb3x57bjzC/LKzCe3em =Ie8l -----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 |