Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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.
I realize it is problem to have the function in two places in our code,
but if we don't make a user-accessible version, every application has to
roll their own version and update it for our system catalog changes.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
