Re: pg_upgrade libraries check
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade libraries check |
Дата | |
Msg-id | 20120529180944.GH20260@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade libraries check (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_upgrade libraries check
|
Список | pgsql-hackers |
On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: