Re: [PATCHES] [pgsql-patches] pg_get_domaindef
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
Re: [PATCHES] [pgsql-patches] pg_get_domaindef
On Wed, 21 Feb 2007 09:10, Bruce Momjian wrote: Hi, Following up this patch with a contribution statement. 'With permission from the Managing Director, Fujitsu Australia Software Technology, I am granting the PostgreSQL Global Development Group the non-revokable right to distribute the source code in this patch under the BSD license.' Rgds, Arul Shaji > I always felt is was better for us to have server functions that return > schema-specific data rather than require every application to define its > own functions. I realize they are duplicated in pg_dump, but even if we > made an external library that pg_dump could share with applications, > would it only be available to C applications? That seems quite > limiting. > > Of course, if people don't need these functions, then we shouldn't have > them. > > Seems we have to decide on this one so we can update the TODO or apply > the patch. > > --- > > 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 > > 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 > > > > ---(end of broadcast)--- > > TIP 2: Don't 'kill -9' the postmaster 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [pgsql-patches] pg_get_domaindef
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
