Re: [HACKERS] Are we losing momentum?

Sean Chittenden <sean(at)chittenden(dot)org> writes:
>> Keep in mind though that there was already talk of migrating most of
>> the \d functionality to the backend (primarily as a way of
>> decoupling psql from catalog version changes). If we were to do
>> that, it would make good sense to make it accessible via SHOW as
>> well. IMHO anyway.

> :-/ Yeah, I've been following that from a distance and I'm not so wild
> about that. I really like that the information_schema has been
> integrated into the base, but translating the SHOW commands into
> SELECTs from information_schema on the backend seems like a bad idea
> unless its going to be done abstract enough via some kind of rewrite
> engine that allows users to program the database to translate their
> verbiage into SQL (ex: KILL -> DROP, GET -> SELECT), which could be
> kinda fun.

Well, I don't want to convert \d into selects from information_schema,
primarily because that would constrain us to showing only things that
are known to the SQL spec --- goodbye, Postgres-specific features
(such as user-definable operators).

I was, however, wondering whether the backend internal support for
"SHOW tables" couldn't be simply to translate it to "SELECT * FROM
some_view". Then it'd be possible for people to customize the output by
replacing the view definition.

> Getting back to SHOW, what do you want to show or not show? Does the
> backend show what's most user friendly? If that's the case, do you
> only show tables that a user has SELECT access to? Does SHOW return
> tuples like a SELECT? What if a SHOW statement doesn't show what the
> user is interested in (view definitions)?

I thought you only wanted MySQL-equivalent functionality here ;-).
Don't tell me they have customizable SHOW output ...

> The information_schema.* tables/views are the SQL sanctioned interface
> that the backend provides.

This argument sounds great in the abstract, but it falls down as soon as
you consider the reality that we want to support things that aren't
SQL-sanctioned. Now, we could define some views that are *not* exactly
INFORMATION_SCHEMA, but at that point the claim that it's a stable
standard interface is looking a lot weaker :-(

regards, tom lane