> 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.
Easy enough to accomplish for the most part. I suppose the most
difficult part is whether we support arbitrary syntax?
SHOW INDEXES ON TABLE <bleah>;
SHOW TABLES;
SHOW DATABASES;
SHOW COLUMNS FROM <table>; <-- Long form of DESCRIBE <table>
I believe all of the above is valid MySQL syntax, so we would need to be
able to work with a list of colId, rather than a single one.
This does not help with tab completion or help for the above items.
Though one could certainly argue help on available commands should come
from the backend, and psql could be taught how to read the table to
determine how to deal with tab completion.
One significant downside is that describe commands would require an
initdb when updated.
Oh, if it's the backend doing the work, the queries should probably be
functions, not free-form queries. Simply makes it easier to inject
variables into the right place. In the initial patch, psql is using a
prepared statement for this work with the side benefit that the plan is
cached. An SQL function would accomplish the same thing.
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
