Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. plpython: Streamline initialization

  2. plpython: Remove duplicate PyModule_Create()

  3. plpython: Clean up PyModule_AddObject() uses

  4. plpython: Remove commented out code

  1. PL/Python initialization cleanup

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-31T08:47:32Z

    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.
    
  2. Re: PL/Python initialization cleanup

    Chao Li <li.evan.chao@gmail.com> — 2025-12-31T23:34:53Z

    
    > On Dec 31, 2025, at 16:47, Peter Eisentraut <peter@eisentraut.org> wrote:
    > 
    > 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.
    > <v1-0001-plpython-Remove-commented-out-code.patch><v1-0002-plpython-Clean-up-PyModule_AddObject-uses.patch><v1-0003-plpython-Remove-duplicate-PyModule_Create.patch><v1-0004-plpython-Streamline-initialization.patch>
    
    I just did an eyeball review. Overall looks good to me. The cleanup, as explained in the patch email, makes sense to me. Only a nit comment on 0002:
    
    1 - 0002
    ```
    +	if (PyModule_AddObject(mod, modname, exc) < 0)
    +	{
    +		Py_XDECREF(exc);
    +		PLy_elog(ERROR, "could not add exceptions %s", name);
    +	}
    ```
    
    Plural “exceptions” is a little confusing. What about “could not add exception object”?
    
    Best regards,
    --
    Chao Li (Evan)
    HighGo Software Co., Ltd.
    https://www.highgo.com/