SHOW TABLES
in [PgSql]
|
From: Andres Freund on 18 Jul 2010 14:58 On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote: > SHOW ANY TABLE > GROUP BY tablename > HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype]; Why is that in *any* way better than SELECT * FROM meta.tables .... Oh. The second looks like something I know. Oh. My editor maybe as well? Oh. And some other tools also? Your syntax also forgets that maybe I only need a subset of the information. I am quite a bit surprised about all this discussion. I have a very hard time we will find anything people agree about and can remember well enough to be usefull for both manual and automatic processing. I agree that the internal pg_* tables are not exactly easy to query. And that the information_schema. ones arent complete enough and have enough concept mismatch to be confusing. But why all this? Andres -- 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: "Kevin Grittner" on 18 Jul 2010 15:00 Dimitri Fontaine <dfontaine(a)hi-media.com> wrote: > So what we'd need first is a series of named queries, which I > think psql provides for. Any solution which only works within psql isn't a solution for a large part of the problem space people are trying to address. One important goal is that if someone spends a day to whip up a GUI query tool (as I did when I first started working in Java), it's easy to get displays like we get from the psql backslash commands (as it was in Sybase, which is what we were using at the time, through sp_help and related stored procedures). While the four DBAs use psql heavily, the twenty-some programmers and the business analysts all use various GUI tools which either tie in to their normal environments (for example, eclipse) or are web based hacks which probably didn't take much more effort than the above-mentioned GUI hack which I used for about ten years. Backslash commands do them no good whatsoever, nor will any solution which requires psql. It would be nice if when I display information about a table or some other database object, I could copy from my psql session, paste it into an email, and they could replicate the behavior in squirrel (or whatever the heck else they happen to be running). -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: Rob Wultsch on 18 Jul 2010 15:02 On Sun, Jul 18, 2010 at 11:58 AM, Andres Freund <andres(a)anarazel.de> wrote: > On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote: >> SHOW ANY TABLE >> GROUP BY tablename >> � HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype]; > Why is that in *any* way better than > > SELECT * > FROM meta.tables > ... > > Oh. The second looks like something I know. Oh. My editor maybe as well? Oh. > And some other tools also? > > Your syntax also forgets that maybe I only need a subset of the information. > > I am quite a bit surprised about all this discussion. I have a very hard time > we will find anything people agree about and can remember well enough to be > usefull for both manual and automatic processing. > > I agree that the internal pg_* tables are not exactly easy to query. And that > the information_schema. ones arent complete enough and have enough concept > mismatch to be confusing. But why all this? > > Andres > Do you have an alternative suggestion for emulating "SHOW SCHEMAS" "SHOW TABLES" "DESC object"? Make a user friendly interface is not easy, but it sure as heck is important. -- Rob Wultsch wultsch(a)gmail.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: Stefan Kaltenbrunner on 18 Jul 2010 15:11 On 07/18/2010 08:58 PM, Andres Freund wrote: > On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote: >> SHOW ANY TABLE >> GROUP BY tablename >> HAVING array_agg(attributes) @> array['date'::regtype, 'time'::regtype]; > Why is that in *any* way better than > > SELECT * > FROM meta.tables > ... > > Oh. The second looks like something I know. Oh. My editor maybe as well? Oh. > And some other tools also? > > Your syntax also forgets that maybe I only need a subset of the information. > > I am quite a bit surprised about all this discussion. I have a very hard time > we will find anything people agree about and can remember well enough to be > usefull for both manual and automatic processing. > > I agree that the internal pg_* tables are not exactly easy to query. And that > the information_schema. ones arent complete enough and have enough concept > mismatch to be confusing. But why all this? exactly my thoughts - but as I said earlier maybe this is actually an opportunity to look at newsysviews again? Stefan -- 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: Andres Freund on 18 Jul 2010 15:21
Hi, On Sunday 18 July 2010 21:02:59 Rob Wultsch wrote: > On Sun, Jul 18, 2010 at 11:58 AM, Andres Freund <andres(a)anarazel.de> wrote: > > On Sunday 18 July 2010 20:39:07 Dimitri Fontaine wrote: > >> SHOW ANY TABLE > >> GROUP BY tablename > >> HAVING array_agg(attributes) @> array['date'::regtype, > >> 'time'::regtype]; > > > > Why is that in *any* way better than > > > > SELECT * > > FROM meta.tables > > ... > > > > Oh. The second looks like something I know. Oh. My editor maybe as well? > > Oh. And some other tools also? > > > > Your syntax also forgets that maybe I only need a subset of the > > information. > > > > I am quite a bit surprised about all this discussion. I have a very hard > > time we will find anything people agree about and can remember well > > enough to be usefull for both manual and automatic processing. > > > > I agree that the internal pg_* tables are not exactly easy to query. And > > that the information_schema. ones arent complete enough and have enough > > concept mismatch to be confusing. But why all this? > Do you have an alternative suggestion for emulating > "SHOW SCHEMAS" > "SHOW TABLES" > "DESC object"? I personally still fail to see the point of emulating it. Maybe building a short wrapper pointing to the docs or whatever. But thats not the point. Providing an easy wrapper is something I could agree without much problems (as it doesnt touch me). But starting several new toplevel commands which do not give everything (i.e. the ability to selectively use columns) but still want to provide a more or less complete query language and should be sensibly usable in subqueries et al - thats another thing. That would involve significant parts of the gram.y, some parts of the parse analysis and the executor for not enough benefit compared to the significant cost. > Make a user friendly interface is not easy, but it sure as heck is > important. From my pov making it easier to query the system (either through functions or views) is a worthwile goal though, dont misunderstand me. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |