On Thu, May 31, 2012 at 06:24:04PM -0400, Tom Lane wrote:
> 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.
Agreed. I think the big question is whether the 8.1 move of the PL
language support functions to pg_catalog should have suppressed dumping
the pre-8.1 PL functions in the public schema.
Another question is whether having these functions in two schemas
presents any possible danger. Users using pg_dumpall and restoring (not
using pg_upgrade) will have the plpython functions removed because they
will error out, so maybe we should just let the plpython renaming trim
those out. However, this doesn't remove the other PL lanauge
duplicates.
I share Tom's caution on this, but I think we need to make sure we are
addressing any possible risk of an isolated pg_upgrade fix, now that we
understand the cause.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +