Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> On 2018-Jan-29, David Fetter wrote:
>> We could certainly have \d call DESCRIBE for later versions of the
>> server. \ commands which call different SQL depending on server
>> version have long been a standard practice.
> So what is the uptake on implementing this at the server side, ie.
> DESCRIBE?
I'm pretty skeptical of this idea, unless you are willing to throw
away at least one and possibly both of the following goals:
1. Compatibility with psql's existing \d behavior.
2. Usability of DESCRIBE for any purpose whatsoever other than emitting
something that looks just like what psql prints.
We've migrated many of the \d displays so far away from "a single query
result" that I don't believe there's a way for a server command to
duplicate them, at least not without some seriously unholy in-bed-ness
between the server command and some postprocessing logic in describe.c.
(At which point you've lost whatever system architectural value there
might be in the whole project, since having a more-arm's-length
relationship there kinda seems like the point to me.)
There are a bunch of other little behavioral differences that you just
can't replicate server-side, like the fact that localization of the
results depends on psql's LC_MESSAGES not the server's. Maybe people
would be okay with changing that, but it's not a transparent
reimplementation.
I think if we want to have server-side describe capability, we're better
off just to implement a DESCRIBE command that's not intended to be exactly
like \d anything, and not try to make it be the implementation for \d
anything. (This was, in fact, where David started IIUC. Other people's
sniping at that idea hasn't yielded any better idea.)
In particular, I'm really strongly against having "\describe-foo-bar"
invoke DESCRIBE, because (a) that will break compatibility with the
existing \des command, and (b) it's not actually saving any typing,
and (c) I think it'd confuse users no end.
Of course, this line of thought does lead to the conclusion that we'd be
maintaining psql/describe.c and server-side DESCRIBE in parallel forever,
which doesn't sound like fun. But we should be making DESCRIBE with an
eye to more use-cases than psql. If it allows jdbc to not also maintain
a pile of equivalent code, that'd be a win. If it allows pg_dump to toss
a bunch of logic overboard (or at least stop incrementally adding new
variants), that'd be a big win.
regards, tom lane
