I have remove this TODO item:

        * %Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
          pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
          These would be for application use, not for use by pg_dump.

Seems there is lack of interest in adding this feature because of
maintanance concerns.

The attached patch is rejected for the same reason.  Sorry for the


FAST PostgreSQL wrote:
> On Thu, 25 Jan 2007 02:25, Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > > FAST PostgreSQL wrote:
> > >> Please find attached the patch with modifications
> > >
> > > are you proposing to implement the other functions in this TODO item
> > > (pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
> > > pg_get_tabledef(), pg_get_functiondef() ) ?
> >
> > I haven't entirely understood the use case for any of these.  It's not
> Any consensus on these functions? If we decide against having these then its 
> better to remove them from the TODO list temporarily/permanently.........
> Rgds,
> Arul Shaji
> > pg_dump, for a number of reasons: one being that pg_dump still has to
> > support older backend versions, and another being that every time we
> > let backend SnapshotNow functions get involved, we take another hit to
> > pg_dump's claim to produce a consistent MVCC snapshot.
> >
> > But my real objection is: do we really want to support duplicative code
> > in both pg_dump and the backend?  Updating pg_dump is already a major
> > PITA whenever one adds a new feature; doubling that work isn't
> > attractive.  (And it'd be double, not just a copy-and-paste, because of
> > the large difference in the operating environment.)  So I want to hear a
> > seriously convincing use-case that will justify the maintenance load we
> > are setting up for ourselves.  "Somebody might want this" is not
> > adequate.
> >
> > Perhaps a better area of work would be the often-proposed refactoring of
> > pg_dump into a library and driver program, wherein the library could
> > expose individual functions such as "fetch the SQL definition of this
> > object".  Unfortunately, that'll be a huge project with no payoff until
> > the end...
> >
> >                     regards, tom lane
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 
> 003 693 481. It is confidential to the ordinary user of the email address to 
> which it was addressed and may contain copyright and/or legally privileged 
> information. No one else may read, print, store, copy or forward all or any 
> of it or its attachments. If you receive this email in error, please return 
> to sender. Thank you.
> If you do not wish to receive commercial email messages from Fujitsu 
> Australia Software Technology Pty Ltd, please email [EMAIL PROTECTED]
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>                http://www.postgresql.org/docs/faq

  Bruce Momjian  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to