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
confusion.
---------------------------------------------------------------------------
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
