Hi,
On Sunday 18 July 2010 21:02:59 Rob Wultsch wrote:
> On Sun, Jul 18, 2010 at 11:58 AM, Andres Freund <andres@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