From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade libraries check |
Date: | 2012-05-29 17:46:28 |
Message-ID: | 14966.1338313588@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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).
> 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".
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-05-29 18:09:44 | Re: pg_upgrade libraries check |
Previous Message | Tom Lane | 2012-05-29 17:27:39 | Re: Bogus nestloop rows estimate in 8.4.7 |