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

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

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Date: 2012-05-31 23:45:32
Message-ID: 4FC8029C.6030400@gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On 05/31/2012 03:30 PM, Bruce Momjian wrote:
> On Thu, May 31, 2012 at 06:24:04PM -0400, Tom Lane wrote:

>>
>> 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.

There are two different things at work here. One the duplicate 
functions, two the renaming of the plpython libraries. The first would 
not have been an issue without the second. I still say for compatibility 
the plpython libraries should follow a scheme that reflects how the 
language is being handled in the database:

plpython.so -> plpython2.so
plpython2.so
plpython3.so (optional)

Not sure if that is possible, just my 2 cents.

In any case the overriding issue would seem to be covered in another 
thread on --hackers 'pg_upgrade libraries check' In other words 
determining who is responsible for tracking library changes?

>


-- 
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com

In response to

pgsql-bugs by date

Next:From: Edmund HornerDate: 2012-06-01 00:14:53
Subject: Re: 9.2 beta1 libxml2 can't be loaded on Windows
Previous:From: Tom LaneDate: 2012-05-31 22:53:17
Subject: Re: BUG #6671: Killed restore command causes postmaster to exit

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