Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),

"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> One thing that I think should be clarified... why wouldn't pg_dump be
> able to use these functions? Is it because of version compatability?

This has already been gone over more than once in this thread, let
alone the prior one, but here are some reasons:

* Unless you want to abandon pg_dump support for prior server versions,
these functions won't really help it. The pg_dump code is structured to
assemble CREATE commands from spare parts; it would be a real mess to do
things significantly differently for some server versions than others.
It certainly wouldn't make pg_dump any smaller or simpler.

* pg_dump doesn't always *want* a unified CREATE command, eg it has to
be able to pull apart tables and their constraints and even sometimes
their default expressions, both for performance and to break circular
references.

* The existing approach makes it possible for pg_dump to adjust syntax
for newer releases when dumping from an older server; functions inside
the older server couldn't do that. Similarly, the existing approach
sometimes makes it possible for pg_dump to work around bugs in older
servers. We've done both these things in the past and it's reasonable
to assume we'll need to again.

* Functions inside the backend are probably going to use SnapshotNow
semantics for inspecting the catalogs. (Avoiding this would generally
mean not depending on *any* existing backend infrastructure such as
catcaches.) This is very bad from pg_dump's standpoint because pg_dump
wants to deliver a consistent snapshot of the way things were when it
started its transaction. Arguably, all the places where pg_dump already
depends on backend functions are broken. (This isn't too bad for table-
related stuff, because pg_dump acquires AccessShareLock which blocks
table DDL changes before it does anything with a table, but I worry
about it in connection with types and functions and so on.)

Basically, going over to a scheme where most of pg_dump's smarts are in
the backend would eliminate the strategy we often recommend of "use the
newer pg_dump when dumping from your older server in preparation for a
major version upgrade". The newer pg_dump couldn't do anything
different from the older one, if both are mostly reliant on code inside
the older server. We've had to recommend that approach often enough
that I am not pleased by the prospect of giving up the option in future.

regards, tom lane