Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Date
Msg-id 22498.1338503044@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2  (Adrian Klaver <adrian.klaver@gmail.com>)
Responses Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
Adrian Klaver <adrian.klaver@gmail.com> writes:
> On 05/31/2012 11:53 AM, Bruce Momjian wrote:
>> On Tue, May 29, 2012 at 10:34:16PM -0400, Bruce Momjian wrote:
>> 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.

> I would say the pg_dump fix. That one gets rid of the duplicates for
> everyone, not just those folks using pg_upgrade.

Hm, I'm not sure about that.  The general charter of pg_dump is to
produce a dump that will replicate the state of the database.
Editorializing on it in order to make it more likely to reload in a
different version of PG seems to violate that charter.

I think the current state where pg_upgrade just complains about those
functions and tells you to remove them by hand is far safer than
creating blind spots in pg_dump.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2