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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Date: 2012-05-31 22:24:04
Message-ID: 22498.1338503044@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Adrian Klaver <adrian(dot)klaver(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2012-05-31 22:30:30 Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Previous Message Adrian Klaver 2012-05-31 20:37:09 Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2