Noah Misch <n...@leadboat.com> writes: > On Wed, Feb 19, 2020 at 08:42:36PM +0100, Peter Eisentraut wrote: >> I think there should just >> be an option "plpython is: {2|3|don't build it at all}". Then packagers can >> match this to what their plan for /usr/bin/python* is -- which appears to be >> different everywhere.
> Today, we do not give packagers this sort of discretion over SQL-level > behavior. We formerly had --disable-integer-datetimes, but I view that as the > lesser of two evils, the greater of which would have been to force dump/reload > of terabyte-scale clusters. We should continue to follow today's principle, > which entails not inviting packagers to align the nature of "LANGUAGE > plpythonu" with the nature of /usr/bin/python. FWIW, I've abandoned this patch. We've concluded (by default, at least) that nothing is getting done in v13, and by the time v14 is out it will be too late to have any useful effect. I expect that the situation on-the-ground by 2021 will be that packagers build with PYTHON=python3 and package whatever they get from that. That means (1) plpythonu won't exist anymore and (2) users will be left to their own devices to convert existing plpython code. Now, (1) corresponds to not providing any /usr/bin/python executable, only python3 -- and that is a really common choice for distros to make, AFAIK, so I don't feel too awful about it. I find (2) less than ideal, but there's evidently not enough interest in doing anything about it. There's certainly going to be no point in shipping a solution for (2) if we fail to do so before v14; people will already have done the work by hand. We should, however, consider updating the plpython docs to reflect current reality. Notably, the existing wording in section 45.1 suggests that we'll eventually redefine "plpythonu" as Python 3, and it seems to me that that's not going to happen. regards, tom lane