Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group