|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
|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|