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.

38 lines
1 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 2025 Backpatch-through: 13
2025-01-01 11:21:55 -05:00
* Portions Copyright (c) 1996-2025, 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
/*
Hide warnings from Python headers when using gcc-compatible compiler. Like commit 388e80132, use "#pragma GCC system_header" to silence warnings appearing within the Python headers, since newer Python versions no longer worry about some restrictions we still use like -Wdeclaration-after-statement. This patch improves on 388e80132 by inventing a separate wrapper header file, allowing the pragma to be tightly scoped to just the Python headers and not other stuff we have laying about in plpython.h. I applied the same technique to plperl for the same reason: the original patch suppressed warnings for a good deal of our own code, not only the Perl headers. Like the previous commit, back-patch to supported branches. Peter Eisentraut and Tom Lane Discussion: https://postgr.es/m/ae523163-6d2a-4b81-a875-832e48dec502@eisentraut.org
2023-12-26 16:16:29 -05:00
* Pull in Python headers via a wrapper header, to control the scope of
* the system_header pragma therein.
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
*/
Hide warnings from Python headers when using gcc-compatible compiler. Like commit 388e80132, use "#pragma GCC system_header" to silence warnings appearing within the Python headers, since newer Python versions no longer worry about some restrictions we still use like -Wdeclaration-after-statement. This patch improves on 388e80132 by inventing a separate wrapper header file, allowing the pragma to be tightly scoped to just the Python headers and not other stuff we have laying about in plpython.h. I applied the same technique to plperl for the same reason: the original patch suppressed warnings for a good deal of our own code, not only the Perl headers. Like the previous commit, back-patch to supported branches. Peter Eisentraut and Tom Lane Discussion: https://postgr.es/m/ae523163-6d2a-4b81-a875-832e48dec502@eisentraut.org
2023-12-26 16:16:29 -05:00
#include "plpython_system.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
/* 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