On 05/27/2012 12:50 PM, Bruce Momjian wrote:
On Sun, May 27, 2012 at 12:31:09PM -0400, Andrew Dunstan wrote:
On 05/27/2012 11:31 AM, Tom Lane wrote:
Having said that, I've got to also say that I think we've fundamentally
blown it with the current approach to upgrading extensions. Because we
dump all the extension member objects, the extension contents have got
to be restorable into a new database version as-is, and that throws away
most of the flexibility that we were trying to buy with the extension
mechanism. IMO we have *got* to get to a place where both pg_dump and
pg_upgrade dump extensions just as "CREATE EXTENSION", and the sooner
the better. Once we have that, this type of issue could be addressed by
having different contents of the extension creation script for different
major server versions --- or maybe even the same server version but
different python library versions, to take something on-point for this
discussion. For instance, Andrew's problem could be dealt with if the
backport were distributed as an extension "json-backport", and then all
that's needed in a new installation is an empty extension script of that
name.
It sounds nice, but we'd have to make pg_upgrade drop its current
assumption that libraries wanted in the old version will be named
the same (one for one) as the libraries wanted in the new version.
Currently it looks for every shared library named in probin (other
than plpgsql.so) in the old cluster and tries to LOAD it in the new
cluster, and errors out if it can't.
I didn't fully understand this. Are you saying pg_upgrade will check
some extension config file for the library name?
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
