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.kla...@gmail.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
