Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2

On Tue, May 29, 2012 at 07:13:24PM -0700, Adrian Klaver wrote:
> >This moved the helper functions into pg_catalog, but the author probably
> >didn't realize that public schema helper functions would continue to be
> >dumped by pg_dump. These helper functions continued to be
> >dumped/restored until the rename. There are certainly helper functions
> >for other languages that are still duplicated in the public schema ---
> >there is nothing unique about plpython. We are only seeing problems
> >because of the plpython.so rename.
>
> Yes, I had the same layout for plpgsql. Already got rid of the public entry.

OK, confirmed then.

> >We could do the same for other PL languages if they are ever renamed. I
> >suppose we don't care about fixing the duplicate schema entries.
>
> Not sure what duplicate entries you are referring to. The two
> pg_catalog entries refer to different handlers, the call handler and
> the inline handler.

My point is that plpython_call_handler is defined in the public and
pg_catalog schema, as are other language handlers.

In fact, an argument could be made that the bug is really in pg_dump.
When we moved the language handlers into pg_catalog, I don't think any
effort was made to suppress the public schema handlers from being dumped.
Maybe that's where the fix should be. It would allow us to fix all the
languages, not just plpython when using pg_upgrade. I think the big
question is can we uniquely identify them.

I did see this C comment in pg_dump.c:

/*
* Determine whether we want to dump definitions for procedural languages.
* Since the languages themselves don't have schemas, we can't rely on
* the normal schema-based selection mechanism. We choose to dump them
* whenever neither --schema nor --table was given. (Before 8.1, we used
* the dump flag of the PL's call handler function, but in 8.1 this will
* probably always be false since call handlers are created in pg_catalog.)
*
* For some backwards compatibility with the older behavior, we forcibly
* dump a PL if its handler function (and validator if any) are in a
* dumpable namespace. That case is not checked here.
*
* Also, if the PL belongs to an extension, we do not use this heuristic.
* That case isn't checked here either.
*/
static bool
shouldDumpProcLangs(void)

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +