From: "Kevin Grittner" on
Stefan Kaltenbrunner <stefan(a)kaltenbrunner.cc> wrote:
> On 07/18/2010 08:58 PM, Andres Freund wrote:

>> 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?

I can't picture anything which could be done with views which would
allow me to issue one statement and see everything of interest about
a table (etc.). You know: tablespace, owner, permissions, columns,
primary key, foreign keys, check constraints, exclusion constraints,
ancestor tables, child tables, and whatever interesting features I
missed or we later add. Other products allow that to be generated
server-side, so that it is available to any and all clients. I
think we should join the crowd in this respect.

-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: Dimitri Fontaine on
Le 18 juil. 2010 � 21:00, Kevin Grittner a �crit :
> 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.

Exactly. It's all about having it in the backend, in an easy to share format.

But what kind of facilities are we talking about?
For me, those catalog queries psql already implements. I don't think we should offer \d or whatever in the backend as is, but the queries that \d uses should be a SHOW <object> away.

Now this subthread is about having a hard coded facility or the full blown SQL atop.
--
Dimitri Fontaine
PostgreSQL DBA, Architecte






--
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
Le 18 juil. 2010 � 20:58, Andres Freund a �crit :
> 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
> ...

There are two questions here I think, really.

First is about having meta-data queries in the backend, and we want that because we want it to be easy for everybody to have access to those, whether they choose to use psql or whatever else.

Second is about why having SHOW be usable as if it where a "real" SQL query? That's because it's been said that people will certainly want to go further away using the facility. And now they want full SQL.

So it seems to me we're now trying to catch 2 birds with a single 'SHOW' stone.
--
Dimitri Fontaine
PostgreSQL DBA, Architecte






--
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
Le 18 juil. 2010 � 21:21, Andres Freund a �crit :
> 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.

Agreed that wanting 'SHOW' commands to be full blown SQL is somewhat strange and "pushing it".
But people on the list wanted to gather ideas on how to do it before deciding its cost is higher than what it's worth, I guess.

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: Simon Riggs on
On Sun, 2010-07-18 at 20:39 +0200, Dimitri Fontaine wrote:

> SHOW TABLE foo;

Yes

> SHOW TABLES WHERE tablename ~ 'foo';
>
> SHOW ANY TABLE
> GROUP BY tablename
> HAVING array_agg(attributes) @> array['date'::regtype,
> 'time'::regtype];

For me, realistically, No.

Simplifying SQL should be left to the SQL standards committee. It could
certainly use a hand there, but its too big a mountain too climb, for
me.

--
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