PL/Python initialization cleanup

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: PL/Python initialization cleanup
Date: 2025-12-31 08:47:32
Message-ID: f31333f1-fbb7-4098-b209-bf2d71fbd4f3@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As I was working through steps to make PL/Python more thread-safe, I
noticed that the initialization code of PL/Python is pretty messy. I
think some of this has grown while both Python 2 and 3 were supported,
because they required different initialization steps, and we had some
defenses against accidentally running both at the same time. But that
is over, and right now a lot of this doesn't make sense anymore. For
example, the function PLy_init_interp() said "Initialize the Python
interpreter ..." but it didn't actually do this, and PLy_init_plpy()
said "initialize plpy module" but it didn't do that either (or at least
they used the term "initialize" in non-standard ways).

Here are some patches to clean this up. After this change, all the
global initialization is called directly from _PG_init(), and the plpy
module initialization is all called from its registered initialization
function PyInit_plpy(). (For the thread-safety job, the plpy module
initialization will need to be rewritten using a different API. That's
why I'm keen to have it clearly separated.) I also tried to add more
comments and make existing comments more precise. There was also some
apparently obsolete or redundant code that could be deleted.

Surely, all of this will need some more rounds of careful scrutiny, but
I think the overall code arrangement is correct and an improvement.

Attachment Content-Type Size
v1-0001-plpython-Remove-commented-out-code.patch text/plain 870 bytes
v1-0002-plpython-Clean-up-PyModule_AddObject-uses.patch text/plain 3.0 KB
v1-0003-plpython-Remove-duplicate-PyModule_Create.patch text/plain 864 bytes
v1-0004-plpython-Streamline-initialization.patch text/plain 5.3 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-12-31 09:01:32 Re: Fix casting away const in _bt_reorder_array_cmp
Previous Message Bertrand Drouvot 2025-12-31 08:42:48 Re: Don't cast away const where possible