On Wed, 24 Jan 2007, 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.
I was talking to AndrewSN on irc about this. He proposed that we supply
two versions (yes I hear the collective groan) of the SQL functions: a
fast one (SnapshotNow) and an accurate one (which doesn't use
SnapshotNow).
The accurate version is important not just for pg_dump but for a host of
people who interact with the system catalogs. If anyone's wondering why
people are interacting with system catalogs in the first place, they need
look know further than a monitoring application which checks system health
and sanity on a regular basis. Combine that with some of the SnapshotNow
based get def functions and common enough DDL (like temp table creation)
and you start getting errors which look much more serious than what they
are.
Implementing the accurate version might be done via SPI. This is a
headache though. It's starting to look like pulling the guts out of
pg_dump and putting it in a library :-). Maybe the read place for this is
actually pgfoundry?
Thanks,
Gavin
