Re: Immodest Proposal: pg_catalog.pg_ddl

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

In response to

Responses

Browse pgsql-hackers by date

  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