Mark Gibson <[EMAIL PROTECTED]> writes:
> I have an idea, to break pg_dump into functions within PostgreSQL.
This strikes me as largely useless, because the problems that are
actually hard for pg_dump are not at the level of individual objects;
they have to do with problems like determining a safe dump order and
altering definitions to break circularities in the dump requirements.
I don't think that extending the pg_get_xxx family of functions would
make pg_dump's life easier by any measurable amount.
There is also a fundamental problem with the current pg_get_xxx
functions, which is that they rely on backend-internal catalog
operations that generally use SnapshotNow semantics. This is not what
we want to guarantee that pg_dump dumps a consistent snapshot --- we
need to look at catalog rows that existed as of pg_dump's serializable
snapshot, instead. We have gotten away with it so far because pg_dump
starts by taking read locks on every table in sight, and that is
sufficient to block schema changes on the tables. But extending the
pg_get_xxx approach to non-table-related objects would be seriously
dangerous. (I think pg_get_viewdef is already broken, actually,
since you can't lock a view.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
