Hi,
On 2022-03-07 15:05:03 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.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
