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

From Bruce Momjian
Subject Re: Immodest Proposal: pg_catalog.pg_ddl
Date
Msg-id 200512171418.jBHEIr501810@candle.pha.pa.us
Whole thread Raw
In response to Re: Immodest Proposal: pg_catalog.pg_ddl  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
List pgsql-hackers
Christopher Kings-Lynne wrote:
> >>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.

Functions added to existing TODO entry.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Re: Which qsort is used
Next
From: Volkan YAZICI
Date:
Subject: Re: number of loaded/unloaded COPY rows