upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-02-11 06:43:59 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/pl/plpython/plpython.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

55 lines
1.4 KiB
C
Raw Normal View History

Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
/*-------------------------------------------------------------------------
*
* plpython.h - Python as a procedural language for PostgreSQL
*
Update copyright for 2023 Backpatch-through: 11
2023-01-02 15:00:37 -05:00
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
* Portions Copyright (c) 1994, Regents of the University of California
*
* src/pl/plpython/plpython.h
*
*-------------------------------------------------------------------------
*/
#ifndef PLPYTHON_H
#define PLPYTHON_H
plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE We undefined them to avoid warnings about macro redefinitions. But we haven't fully followed the necessary include order, since at least 147c2482542, in 2011. Recently the combination of the include order rules not being followed and undefining _POSIX_C_SOURCE started to cause a compile failure, starting with 03023a2664f. Undefining _POSIX_C_SOURCE hides clock_gettime(), which is referenced in an inline function as of 03023a2664f, whereas it was a macro before. After seeing some evidence that undefining _POSIX_C_SOURCE et al isn't required, I tried to build postgres with plpython on most of our supported platforms (except DragonFlyBSD and Illumos, but similar systems were tested), with/without the #undefines. No compiler warning / behavioral difference. The oldest supported python version, 3.2, defines _POSIX_C_SOURCE to 200112L ad _XOPEN_SOURCE to 600, whereas newer versions of python use 200809L/700 respectively. As _POSIX_C_SOURCE/_XOPEN_SOURCE will default to the newer operating system on most platforms, it's possible that when using python 3.2 new warnings would be emitted - but that seems acceptable. It's possible that this approach won't work on some older platforms. But getting rid of most of the include-order complexity seems promising, and it's an easily revertible patch if we end up having to go another way. Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de
2023-01-25 12:59:26 -05:00
/* postgres.h needs to be included before Python.h, as usual */
#if !defined(POSTGRES_H)
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
#error postgres.h must be included before plpython.h
plpython: Stop undefining _POSIX_C_SOURCE, _XOPEN_SOURCE We undefined them to avoid warnings about macro redefinitions. But we haven't fully followed the necessary include order, since at least 147c2482542, in 2011. Recently the combination of the include order rules not being followed and undefining _POSIX_C_SOURCE started to cause a compile failure, starting with 03023a2664f. Undefining _POSIX_C_SOURCE hides clock_gettime(), which is referenced in an inline function as of 03023a2664f, whereas it was a macro before. After seeing some evidence that undefining _POSIX_C_SOURCE et al isn't required, I tried to build postgres with plpython on most of our supported platforms (except DragonFlyBSD and Illumos, but similar systems were tested), with/without the #undefines. No compiler warning / behavioral difference. The oldest supported python version, 3.2, defines _POSIX_C_SOURCE to 200112L ad _XOPEN_SOURCE to 600, whereas newer versions of python use 200809L/700 respectively. As _POSIX_C_SOURCE/_XOPEN_SOURCE will default to the newer operating system on most platforms, it's possible that when using python 3.2 new warnings would be emitted - but that seems acceptable. It's possible that this approach won't work on some older platforms. But getting rid of most of the include-order complexity seems promising, and it's an easily revertible patch if we end up having to go another way. Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de
2023-01-25 12:59:26 -05:00
#elif defined(Py_PYTHON_H)
#error Python.h must be included via plpython.h
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
#endif
/*
plpython: Avoid the need to redefine *printf macros Until now we undefined and then redefined a lot of *printf macros due to worries about conflicts with Python.h macro definitions. Current Python.h doesn't define any *printf macros, and older versions just defined snprintf, vsnprintf, guarded by #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF). Thus we can replace the undefine/define section with a single #define HAVE_SNPRINTF 1 Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de
2023-01-25 12:59:26 -05:00
* Python versions <= 3.8 otherwise define a replacement, causing macro
* redefinition warnings.
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
*/
plpython: Avoid the need to redefine *printf macros Until now we undefined and then redefined a lot of *printf macros due to worries about conflicts with Python.h macro definitions. Current Python.h doesn't define any *printf macros, and older versions just defined snprintf, vsnprintf, guarded by #if defined(MS_WIN32) && !defined(HAVE_SNPRINTF). Thus we can replace the undefine/define section with a single #define HAVE_SNPRINTF 1 Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20230124165814.2njc7gnvubn2amh6@awork3.anarazel.de
2023-01-25 12:59:26 -05:00
#define HAVE_SNPRINTF 1
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
#if defined(_MSC_VER) && defined(_DEBUG)
/* Python uses #pragma to bring in a non-default libpython on VC++ if
* _DEBUG is defined */
#undef _DEBUG
/* Also hide away errcode, since we load Python.h before postgres.h */
#define errcode __msvc_errcode
#include <Python.h>
#undef errcode
#define _DEBUG
#elif defined (_MSC_VER)
#define errcode __msvc_errcode
#include <Python.h>
#undef errcode
#else
#include <Python.h>
#endif
/* define our text domain for translations */
#undef TEXTDOMAIN
#define TEXTDOMAIN PG_TEXTDOMAIN("plpython")
/*
plpython: Code cleanup related to removal of Python 2 support. Since 19252e8ec93 we reject Python 2 during build configuration. Now that the dust on the buildfarm has settled, remove Python 2 specific code, including the "Python 2/3 porting layer". The code to detect conflicts between plpython using Python 2 and 3 is not removed, in case somebody creates an out-of-tree version adding back support for Python 2. Reviewed-By: Peter Eisentraut <peter@eisentraut.org> Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20211031184548.g4sxfe47n2kyi55r@alap3.anarazel.de
2022-03-07 21:30:28 -05:00
* Used throughout, so it's easier to just include it everywhere.
Split plpython.c into smaller pieces This moves the code around from one huge file into hopefully logical and more manageable modules. For the most part, the code itself was not touched, except: PLy_function_handler and PLy_trigger_handler were renamed to PLy_exec_function and PLy_exec_trigger, because they were not actually handlers in the PL handler sense, and it makes the naming more similar to the way PL/pgSQL is organized. The initialization of the procedure caches was separated into a new function init_procedure_caches to keep the hash tables private to plpy_procedures.c. Jan Urbański and Peter Eisentraut
2011-12-18 14:14:16 -05:00
*/
#include "plpy_util.h"
#endif /* PLPYTHON_H */
Reference in a new issue Copy permalink