Re: Immodest Proposal: pg_catalog.pg_ddl - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Immodest Proposal: pg_catalog.pg_ddl
Date
Msg-id 43A0C818.8020407@familyhealth.com.au
Whole thread Raw
In response to Re: Immodest Proposal: pg_catalog.pg_ddl  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Immodest Proposal: pg_catalog.pg_ddl  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: psql and COPY BINARY
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Immodest Proposal: pg_catalog.pg_ddl