On Sun, May 27, 2012 at 02:32:52PM -0400, Tom Lane wrote: > 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.
I assumed I could just have pg_upgrade create and drop the extension in the new database to make sure it works. In the JSON backpatch case, the extension file would just do nothing, as has already been suggested. In fact, can we identify right now if a function is used only by an extension? If so, we could try that idea with our existing infrastructure. That would allow extensions to change their shared object file names with no effect on pg_upgrade. This would allow us to skip checking pg_catalog functions because those are now (mostly?) extensions. > 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. What about C triggers and SPI functions. Do we really want to require extension files for them? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
