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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Date: 2012-05-31 18:53:42
Message-ID: 20120531185342.GJ26894@momjian.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs

On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
> 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)

OK, so what do people want me to do on this? Apply my pg_upgrade fix or
go for a more general fix that will prevent pg_dump from dumping out
these duplicate functions --- it would involve checking for public
schema functions who's names and probin match pg_pltemplate entries.
Either will fix pg_upgrade.

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

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message edward 2012-05-31 18:56:13 BUG #6671: Killed restore command causes postmaster to exit
Previous Message Chris Ruprecht 2012-05-31 15:31:13 Re: BUG #6641: uuid.h warning during configure