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 |/