| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | 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-14 15:39:43 |
| Message-ID: | 19666.1134574783@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-12-14 15:48:05 | Re: Interesting speed anomaly |
| Previous Message | Andrew Dunstan | 2005-12-14 15:22:28 | Re: Immodest Proposal: pg_catalog.pg_ddl |