Re: Should PG backend know how to represent metadata?

Something like...
# \D table foo

create table foo ( bar text, baz integer
);

?

Sounds pretty good.

Philip Warner wrote:
> 
> 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   |/