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.klaver@gmail.com
