Andrew Dunstan <and...@dunslane.net> writes:
> AIUI, for Tom's scheme to work pg_upgrade would need not to check
> libraries that belonged to extension functions. Currently it simply
> assumes that what is present in the old cluster is exactly what will be
> needed in the new cluster. Tom's proposed scheme would completely
> invalidate that assumption (which I would argue is already of doubtful
> validity). Instead of explicitly trying to LOAD the libraries it would
> have to rely on the "CREATE EXTENSION foo" failing, presumably at some
> time before it would be too late to abort.
Well, the scheme I had in mind would require pg_upgrade to verify that
the new cluster contains an extension control file for each extension in
the old cluster (which is something it really oughta do anyway, if it
doesn't already). After that, though, it ought not be looking at the
individual functions defined by an extension --- it is the extension's
business which libraries those are in.
The only reason for pg_upgrade to still look at probin at all would be
to cover C functions that weren't within extensions. In the long run it
might be possible to consider those unsupported, or at least not common
enough to justify a safety check in pg_upgrade.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
