postgresql/src/pl/plpython/plpy_planobject.h

/*
 * src/pl/plpython/plpy_planobject.h
 */

#ifndef PLPY_PLANOBJECT_H
#define PLPY_PLANOBJECT_H

#include "executor/spi.h"
#include "plpy_typeio.h"


typedef struct PLyPlanObject
{
	PyObject_HEAD
	SPIPlanPtr	plan;
	int			nargs;
	Oid		   *types;
	Datum	   *values;
	PLyObToDatum *args;
	MemoryContext mcxt;
} PLyPlanObject;

extern void PLy_plan_init_type(void);
extern PyObject *PLy_plan_new(void);
extern bool is_PLyPlanObject(PyObject *ob);

#endif							/* PLPY_PLANOBJECT_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			`/*`
			`* src/pl/plpython/plpy_planobject.h`
			`*/`

			`#ifndef PLPY_PLANOBJECT_H`
			`#define PLPY_PLANOBJECT_H`

			`#include "executor/spi.h"`
			`#include "plpy_typeio.h"`


			`typedef struct PLyPlanObject`
			`{`
			`PyObject_HEAD`
			`SPIPlanPtr plan;`
			`int nargs;`
			`Oid *types;`
			`Datum *values;`
Make PL/Python handle domain-type conversions correctly. Fix PL/Python so that it can handle domains over composite, and so that it enforces domain constraints correctly in other cases that were not always done properly before. Notably, it didn't do arrays of domains right (oversight in commit c12d570fa), and it failed to enforce domain constraints when returning a composite type containing a domain field, and if a transform function is being used for a domain's base type then it failed to enforce domain constraints on the result. Also, in many places it missed checking domain constraints on null values, because the plpy_typeio code simply wasn't called for Py_None. Rather than try to band-aid these problems, I made a significant refactoring of the plpy_typeio logic. The existing design of recursing for array and composite members is extended to also treat domains as containers requiring recursion, and the APIs for the module are cleaned up and simplified. The patch also modifies plpy_typeio to rely on the typcache more than it did before (which was pretty much not at all). This reduces the need for repetitive lookups, and lets us get rid of an ad-hoc scheme for detecting changes in composite types. I added a couple of small features to typcache to help with that. Although some of this is fixing bugs that long predate v11, I don't think we should risk a back-patch: it's a significant amount of code churn, and there've been no complaints from the field about the bugs. Tom Lane, reviewed by Anthony Bykov Discussion: https://postgr.es/m/24449.1509393613@sss.pgh.pa.us 2017-11-16 16:22:57 -05:00			`PLyObToDatum *args;`
Fix memory leaks in PL/Python. Previously, plpython was in the habit of allocating a lot of stuff in TopMemoryContext, and it was very slipshod about making sure that stuff got cleaned up; in particular, use of TopMemoryContext as fn_mcxt for function calls represents an unfixable leak, since we generally don't know what the called function might have allocated in fn_mcxt. This results in session-lifespan leakage in certain usage scenarios, as for example in a case reported by Ed Behn back in July. To fix, get rid of all the retail allocations in TopMemoryContext. All long-lived allocations are now made in sub-contexts that are associated with specific objects (either pl/python procedures, or Python-visible objects such as cursors and plans). We can clean these up when the associated object is deleted. I went so far as to get rid of PLy_malloc completely. There were a couple of places where it could still have been used safely, but on the whole it was just an invitation to bad coding. Haribabu Kommi, based on a draft patch by Heikki Linnakangas; some further work by me 2015-11-05 13:52:30 -05:00			`MemoryContext mcxt;`
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			`} PLyPlanObject;`

			`extern void PLy_plan_init_type(void);`
			`extern PyObject *PLy_plan_new(void);`
PL/Python: Add argument names to function declarations For easier source reading 2011-12-29 15:55:49 -05:00			`extern bool is_PLyPlanObject(PyObject *ob);`
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 /* PLPY_PLANOBJECT_H */`