From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Immodest Proposal: pg_catalog.pg_ddl |
Date: | 2005-12-15 01:34:16 |
Message-ID: | 43A0C818.8020407@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>What I would like to see is some builtin functions that give me the
>>table's DDL, just as pg_dump does. Extra nice would be complementary
>>functions that also give me skeleton select statements for each table or
>>view.
>
>
> Yeah, what I first thought David was proposing was a consolidated view
> similar to pg_indexes, that could give you an up-to-date DDL definition
> for anything in the system. This has been proposed in the past as a way
> to migrate pg_dump functionality into the backend. I don't think it
> will actually work for that (pg_dump needs more understanding of what
> it's doing than just blindly copying complete CREATE commands) --- but
> it still seems potentially useful for manual operations.
We have many pg_get_blahdef() functions already, but we really should
flesh them all out so that they are available for every database object, eg:
pg_get_tabledef()
pg_get_domaindef()
pg_get_functiondef()
etc.
That would also be cool because then I'd have an easy way of dumping
individual objects from phpPgAdmin, or pgAdmin ,etc.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-12-15 01:35:37 | Re: Refactoring psql for backward-compatibility |
Previous Message | Christopher Kings-Lynne | 2005-12-15 01:28:53 | Re: psql and COPY BINARY |