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 |
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 |