On Sun, Jun 4, 2017 at 01:55:01PM -0400, Tom Lane wrote: > > * should we print all the pg_proc.pronames that are involved, not just > > the unique library names > > * should we output a query helping people find the pg_proc entries > > > I think there are many cases where DROP EXTENSION XXX fixes the problem, > > Yes. I think in most cases nowadays there's a one-for-one correlation > between extensions and libraries; drilling down to the level of individual > functions would just be confusing clutter. I think if you just print > a report saying "these libraries are referenced in these databases", > that would be sufficiently usable in most cases.
OK. > You could think about printing a script full of DROP EXTENSION commands, > but aside from the sheer difficulty of doing that, it doesn't seem all > that helpful. Simply dropping every extension is usually *not* the > right answer, and it could easily lead to data loss if done blindly. > Usually people are going to need to stop and think anyway. 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. -- 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
