Re: obsoleting plpython2u and defaulting plpythonu to plpython3u

Pavel Raiskup <praiskup(at)redhat(dot)com> writes:
> On Friday, April 27, 2018 5:51:57 PM CEST Tom Lane wrote:
>> We should evidently plan on making this stuff happen in v12, or we're
>> going to be behind the curve.

> Agreed, but I'm still not sure what would be the expected 2->3 migration
> path. If that change happens in PG v12, people will migrate to that from
> v11 and there's the trouble. Would it technically possible to upgrade
> such clusters with pg_upgrade when 'plpythonu' silently goes from
> 'plpython2.so' to 'plpython3.so' behind the scenes?
> Or is it expected that people will migrate semi-automatically/manually
> from plpython2 to plpython3 on v11 - before hitting pg_upgrade?

Good questions. I think that the most useful thing we could do in the
near term is to cause functions declared with LANGUAGE 'plpythonu'
to be declared with LANGUAGE 'plpython2u' as-stored. It'd then be on
the user's head to migrate at some point, changing that to LANGUAGE
'plpython3u' along with any required changes to the function body.
(This parallels the remarks in the Fedora migration plan about
discouraging packages from referencing "python" with no version number.)
The time frame for doing that would depend on the user's tolerance for
running out-of-support language code and/or their platform's tolerance for
shipping same. I'd imagine it would be quite a long time before PG proper
would say we no longer support python2, but individual distros would stop
shipping those packages whenever their policy dictates.

If we go down that path, then 'plpythonu' isn't really a language anymore,
nor an extension --- it's just an alias that CREATE FUNCTION recognizes
and replaces. In the past we've had needs of that sort and generally just
hacked it with some hard-wired code (see, eg, the overdue-for-retirement
code in ResolveOpClass()). I'm tempted to propose that we handle this
case with something equally grotty, that is basically do this in
CreateFunction:

if (strcmp(language, "plpythonu") == 0)
language = DEFAULT_PYTHON_LANGUAGE;

where DEFAULT_PYTHON_LANGUAGE is defined as either "plpython2u" or
"plpython3u" according to a configure switch. You could imagine
building some significantly more complicated infrastructure, but
I doubt it would be worth the effort; how many other use-cases are
we likely to have?

If we agree that something like this is the way to go, I wonder if we
shouldn't squeeze it into v11. If we wait till v12, that's not going
to ship till late 2019, which is going to be getting uncomfortably
close to when PEP 394 might change if we believe Fedora's schedule.

regards, tom lane