This question comes out of my work on pg_dump. AFAICT, the only way of
showing, eg, the SQL for a procedure definition (other than 'select prosrc
from pg_procs, or whatever'), is to use pg_dump.
This seems strange to me, since I often want to look at a procedure within
psql, and running 'select' on system tables is not my first thought.
I would have thought that the database itself should be the tool used to
display SQL, and if not the database, then one of the interface libraries.
If it were separated from pg_dump, then psql could more easily have a new
"\D table table-name" and "\D rule rule-name" to dump object definitions,
or "\D rules", to dump the names of all rules etc.
The separation would have the further advantage that when a new language
feature is added the person adding it does not have to remember to update
pg_dump, psql etc. And the task might be a little easier, since I would
hope that the code to dump the definition would be close to the code to
parse it.
Does this sound resonable/sensible/worth doing?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
