Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> Where do we want to go with this? It is interesting that it maps MySQL
>> SHOW commands on top of our existing SHOW syntax in psql. The patch
>> doesn't look too big.
> The response to "Are we losing momentum?" isn't to add redundant syntax
> for nonstandard features that we have no control over.
I'm of two minds about it myself. I don't like trying to play follow-the-
leader with a moving target. But if you think of it as trying to win
over converts from MySQL, it seems a lot more palatable.
It would also be interesting to combine this with Rod's idea of driving
describe-type queries by table instead of hardwired code. Imagine that
the backend's "show foo" command first looks for "foo" as a GUC
variable, as it does now, but upon failing to find one it looks in a
system table for a query associated with the name "foo". If it finds
such a query, it runs it and sends back the result. Now, not only can
we emulate "show tables", but people can easily add application-specific
"show whatever" commands, which seems tremendously cool.
There are some safety and protection issues to be solved here (probably
only superusers should be allowed to modify the query table, and we
should restrict the form of the query to be a single SELECT command)
but I can't think of any showstoppers. Now that we've abandoned backend
autocommit there are no technical reasons that SHOW shouldn't be allowed
to run a SELECT query.
I did not care for the original patch (which IIRC made psql recognize
"show" commands, rather than doing it in the backend) but something like
the above seems reasonably clean.
regards, tom lane
