Re: obsoleting plpython2u and defaulting plpythonu to plpython3u

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

In response to

Browse pgsql-hackers by date

  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