On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > 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. > > It seems like checking for the control file being present should be > sufficient. I don't think it's part of pg_upgrade's job description to > test whether the new installation is broken. And we don't really want > it cluttering the new installation with dead objects right off the bat > (could cause OID issues or LSN issues, for instance).
True. I just wasn't sure the control file method was fool-proof enough. > > In fact, can we identify right now if a function is used only by an > > extension? > > ITYM is the function defined by an extension, and the answer to that is > "look in pg_depend". So is this something I should be exploring, or not worth it at this time? It would allow changing the names of extension shared object files, but right now I don't know anyone doing that, so I am not sure of the value of the change. -- 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
