From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Raiskup <praiskup(at)redhat(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: obsoleting plpython2u and defaulting plpythonu to plpython3u |
Date: | 2018-04-27 17:37:32 |
Message-ID: | 20180427173732.alsxuyjigv7o3iaq@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-04-27 13:34:58 -0400, Tom Lane wrote:
> Yeah, there's a separate set of questions about what happens during
> pg_upgrade of a database containing the existing plpythonu extension.
>
> You could imagine hacking the dump/reload case by defining plpythonu
> as an empty extension with a dependency on plpython2u (or, maybe
> someday in future, a dependency on plpython3u). But that won't do
> the trick for binary upgrades; we might need special-case code in
> pg_dump/pg_upgrade to fix that.
One way to deal with that is have an upgrade script that does the
reassignment. Seems a mite cleaner than doing it in pg_dump. We could
just have a query updating pg_depend to reference the new extension
rather than the old. That'd mean we'd be in the "old" situation before
somebody an extension update ran, but that seems hard to avoid?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-04-27 17:38:46 | Re: Toast issues with OldestXmin going backwards |
Previous Message | Tom Lane | 2018-04-27 17:34:58 | Re: obsoleting plpython2u and defaulting plpythonu to plpython3u |