Re: Time to drop plpython2?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Time to drop plpython2?
Date: 2022-03-08 01:00:07
Message-ID: 20220308010007.wbjlxcdlp655re46@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-03-07 15:05:03 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Now that the BF has stabilized, I've rebased and cleaned up the patches I'd
> > posted earlier. Attached for the first time is my attempt at cleaning up the
> > docs.
>
> I looked through this quickly, and have a couple of nitpicks. The
> PGFILEDESC value for jsonb_plpython is worded randomly differently
> from those for hstore_plpython and ltree_plpython. I think we should
> make it match those.

Makes sense.

> I also noted a couple of typos in the docs patch.
> See attached delta patch

Thanks, incorporated.

> I kind of wonder if we still need "46.1. Python 2 vs. Python 3" at
> all. It certainly doesn't seem like it still deserves its position
> of honor as the first subsection. Perhaps move it down to be the
> last subsection?

Agreed. I think it's useful to have it, just so we have a place mentioning
plpython[2]u. I put it as the second last subsection for now, somehow seemed
to belong before the env variable list? But...

> Also, grepping reveals that vcregress.pl still has two stray references to
> "plpythonu".

I left that in somewhat intentionally, it seemed the cleanest way to remove
plpython2 from vcregress.pl. It's purely cosmetic afaics.

A related question is whether we want to remove $(python_majorversion)
references in the makefiles?

> I did not touch that here, but maybe that has something to do with the ci
> failure?

The CI failure was caused by me screwing up search and replace
:(. Accidentally replaced PyString_AsString with PyUnicode_AsString instead of
P*L*yUnicode_AsString.

Somewhat surprised at that causing problems only on windows (even valgrind
didn't, although the required suppressions might have been the cause of
that). But well, better there than nowhere...

> > I did so far leave in the "major version conflict" detection stuff in
> > plpy_main.c - that could again be useful? I'm leaning towards removing it, I'd
> > hope that there's not again such a painful transition, and we have the git
> > history if needed.
>
> I think we should leave it in. I foresee that somebody will want to build
> plpython2u as an out-of-core extension, at least for a few years yet.
> If they do, and the core language does not have its half of that guard,
> it'd be bad.

Makes sense. Added a comment to that effect.

I noticed a few references to PLyString in function names. Probably should
replace them with PLyUnicode. Didn't do that yet in the attached...

Greetings,

Andres Freund

Attachment Content-Type Size
v7-0001-plpython-Remove-plpythonu-plpython2u-and-associat.patch text/x-diff 14.9 KB
v7-0002-plpython-Remove-regression-test-infrastructure-fo.patch text/x-diff 245.8 KB
v7-0003-plpython-Code-cleanup-related-to-removal-of-Pytho.patch text/x-diff 33.8 KB
v7-0004-plpython-Adjust-docs-after-removal-of-Python-2-su.patch text/x-diff 25.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-03-08 01:06:50 Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Previous Message Bruce Momjian 2022-03-08 00:06:08 Re: refreshing query id for pg_stat_statements based on comment in sql