Re: [HACKERS] Are we losing momentum?

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

::nods:: Good point. All the more the reason to put this in the
client. :)

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

Well, my attitude is to arm psql with a good set of defaults (already
has some good ones, IMHO), and having it catch \[token1] [token2] and
SHOW [token1] and translate it into the appropriate query. If it
works out in psql, then leave it. If people complain about it not
being available in the backend, then we can move it there in 8.0. :)

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

Heh, they don't, but letting psql customize what SHOW means would be a
feature that mysql doesn't have and one that'd be reasonably useful,
IMHO.

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

Does the spec preclude us from adding views/tables to the
information_schema that allow information_schema to be a completely
reflective interface into the structure of the backend? I'm worried
that things are out of control because the existing, already in use
backend's system catalogs aren't user friendly (ex: usename ->
username).

-sc

--
Sean Chittenden