On Sun, Jun 4, 2017 at 02:04:37PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > The problem is that in some cases extensions are improperly removed or > > the extension has bugs that leaves pg_proc entries around that aren't > > dumped, but are seen by pg_upgrade and generate an error. In these > > cases, and I have seen a few recently, we don't give the user any way to > > find the cause except ask for assistance, i.e. we don't show them the > > query we used to find the problem libraries. > > Meh. I think that sort of situation is one in which non-experts are > going to need help in any case. It's unlikely that pg_upgrade can, > or should try to, offer them advice sufficient to fix the problem. > > Also, I completely reject the idea that pg_upgrade's output should > be optimized for that situation rather than the typical "you forgot > to install these extensions in the new installation" case.
I didn't want to optimize for it --- I wanted a way to detect when DROP EXTENSION has no hope of working, and give more details. I assume the problem with that is the the object names are inside SQL scripts that cannot be easily interrogated. Are the pg_proc entries tied to the extension in some verifiable way that we could identify orphaned pg_proc lines? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
