From: Rod Taylor <rbt@rbt.ca>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Sean Chittenden <sean@chittenden.org>
Cc: Curt Sampson <cjs@cynic.net>
Cc: Brent Verner <brent@rcfile.org>
Cc: PostgreSQL Patches <pgsql-patches@postgresql.org>
Subject: Re: [HACKERS] Are we losing momentum?
Date: 31 May 2003 23:08:49 -0400
Message-ID: <1054436929.11968.77.camel@jester> (raw)
In-Reply-To: <20930.1054399740@sss.pgh.pa.us>
References: <Pine.LNX.4.44.0305311754110.6382-100000@peter.localdomain>
<20930.1054399740@sss.pgh.pa.us>
> 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.ascAttachments:
signature.asc (application/pgp-signature, 186B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rbt@rbt.ca, tgl@sss.pgh.pa.us, peter_e@gmx.net, pgman@candle.pha.pa.us, sean@chittenden.org, cjs@cynic.net, brent@rcfile.org, pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Are we losing momentum?
In-Reply-To: <1054436929.11968.77.camel@jester>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox