- url="http://www.python.org/doc/FAQ.html#3.30">Python FAQ
- 3.30. On some operating systems you don't really have to
- build a shared library, but then you will have to convince the
- PostgreSQL build system of this. Consult the
- Makefile in the
- src/pl/plpython directory for details.
-
-
-
-
-
Using PL/Python
+
+
PL/Python Functions
- There are sample functions in
- plpython_function.sql. The Python code you
- write gets transformed into a function. E.g.,
+ The Python code you write gets transformed into a function. E.g.,
-CREATE FUNCTION myfunc(text) RETURNS text AS
-'return args[0]'
-LANGUAGE 'plpython';
+CREATE FUNCTION myfunc(text) RETURNS text
+ AS 'return args[0]'
+ LANGUAGE 'plpython';
gets transformed into
def __plpython_procedure_myfunc_23456():
- return args[0]
+ return args[0]
where 23456 is the OID of the function.
If you do not provide a return value, Python returns the default
None which may or may not be what you want. The
- language module translates Python's None into SQL NULL.
+ language module translates Python's None into the
+ SQL null value.
-
PostgreSQL> function variables are available in the global
- args list. In the myfunc
- example, args[0]> contains whatever was passed in as the text
- argument. For myfunc2(text, integer), args[0]>
- would contain the text variable and args[1] the integer variable.
+ The
PostgreSQL> function parameters are available in
+ the global args list. In the
+ myfunc example, args[0]> contains
+ whatever was passed in as the text argument. For
+ myfunc2(text, integer), args[0]>
+ would contain the text variable and
+ args[1] the integer variable.
- The global dictionary SD is available to store data between
- function calls. This variable is private static data. The global
- dictionary GD is public data, available to all python functions
- within a backend. Use with care.
+ The global dictionary SD is available to store
+ data between function calls. This variable is private static data.
+ The global dictionary GD is public data,
+ available to all Python functions within a session. Use with care.
Each function gets its own restricted execution object in the
Python interpreter, so that global data and function arguments from
myfunc are not available to
- myfunc2. The exception is the data in the GD
- dictionary, as mentioned above.
+ myfunc2. The exception is the data in the
+ GD dictionary, as mentioned above.
+
+
+
+
Trigger Functions
- When a function is used in a trigger, the dictionary TD contains
- transaction related values. The trigger tuples are in TD["new"]>
- and/or TD["old"]> depending on the trigger event. TD["event"]>
- contains the event as a string (INSERT>, UPDATE>, DELETE>, or
- UNKNOWN>). TD["when"] contains one of (BEFORE>, AFTER>, or
- UNKNOWN>). TD["level"]> contains one of ROW>, STATEMENT>, or
- UNKNOWN>. TD["name"]> contains the trigger name, and TD["relid"]>
- contains the relation id of the table on which the trigger occurred.
- If the trigger was called with arguments they are available
- in TD["args"][0]> to TD["args"][(n -1)]>.
+ When a function is used in a trigger, the dictionary
+ TD contains trigger-related values. The trigger
+ rows are in TD["new"]> and/or TD["old"]>
+ depending on the trigger event. TD["event"]> contains
+ the event as a string (INSERT>, UPDATE>,
+ DELETE>, or UNKNOWN>).
+ TD["when"]> contains one of BEFORE>,
+ AFTER>, and UNKNOWN>.
+ TD["level"]> contains one of ROW>,
+ STATEMENT>, and UNKNOWN>.
+ TD["name"]> contains the trigger name, and
+ TD["relid"]> contains the relation ID of the table on
+ which the trigger occurred. If the trigger was called with
+ arguments they are available in TD["args"][0]> to
+ TD["args"][(n-1)]>.
- If the trigger when
is BEFORE>, you may return None or "OK"
- from the Python function to indicate the tuple is unmodified,
- "SKIP"> to abort the event, or "MODIFIED"> to indicate you've
- modified the tuple.
+ If the TD["when"] is BEFORE>, you may
+ return None or "OK" from the
+ Python function to indicate the row is unmodified,
+ "SKIP"> to abort the event, or "MODIFIED"> to
+ indicate you've modified the row.
+
+
+
+
Database Access
The PL/Python language module automatically imports a Python module
this module are available to you in the Python code as
plpy.foo. At present
plpy implements the functions
- plpy.debug("msg"),
+ plpy.debug("msg"),
plpy.log("msg"),
plpy.info("msg"),
plpy.notice("msg"),
plpy.warning("msg"),
plpy.error("msg"), and
plpy.fatal("msg"). They are mostly equivalent
- to calling elog(LEVEL>, "msg").
- plpy.error and plpy.fatal
- actually raise a Python exception which, if uncaught, causes the
- PL/Python module to call elog(ERROR, msg) when
- the function handler returns from the Python interpreter. Long
- jumping out of the Python interpreter is probably not good.
- raise plpy.ERROR("msg") and raise
+ to calling elog(LEVEL>, "msg")
+ from C code. plpy.error and
+ plpy.fatal actually raise a Python exception
+ which, if uncaught, causes the PL/Python module to call
+ elog(ERROR, msg) when the function handler
+ returns from the Python interpreter. Long-jumping out of the
+ Python interpreter is probably not good. raise
+ plpy.ERROR("msg") and raise
plpy.FATAL("msg") are equivalent to calling
- plpy.error or plpy.fatal.
+ plpy.error and
+ plpy.fatal, respectively.
- Additionally, the plpy module provides two functions called
- execute and prepare.
- Calling plpy.execute with a query string, and
- an optional limit argument, causes that query to be run, and the
- result returned in a result object. The result object emulates a
+ Additionally, the plpy module provides two
+ functions called execute and
+ prepare. Calling
+ plpy.execute with a query string and an
+ optional limit argument causes that query to be run and the result
+ to be returned in a result object. The result object emulates a
list or dictionary object. The result object can be accessed by
- row number, and field name. It has these additional methods:
+ row number and field name. It has these additional methods:
nrows() which returns the number of rows
returned by the query, and status which is the
SPI_exec return variable. The result object
can be modified.
+
+ For example,
rv = plpy.execute("SELECT * FROM my_table", 5)
- returns up to 5 rows from my_table. Ff my_table has a column
- my_field it would be accessed as
+ returns up to 5 rows from my_table. If
+ my_table has a column
+ my_field, it would be accessed as
foo = rv[i]["my_field"]
+
+
The second function plpy.prepare is called
- with a query string, and a list of argument types if you have bind
- variables in the query.
+ with a query string and a list of argument types if you have bind
+ variables in the query. For example:
plan = plpy.prepare("SELECT last_name FROM my_users WHERE first_name = $1", [ "text" ])
- text is the type of the variable you will be passing as $1. After
- preparing you use the function plpy.execute to
- run it.
+ text is the type of the variable you will be
+ passing as $1. After preparing a statement, you
+ use the function plpy.execute to run it:
rv = plpy.execute(plan, [ "name" ], 5)
plpy.execute.
+ In the current version, any database error encountered while
+ running a
PL/Python function will result
+ in the immediate termination of that function by the server; it is
+ not possible to trap error conditions using Python try
+ ... catch constructs. For example, a syntax error in an
+ SQL statement passed to the plpy.execute() call
+ will terminate the function. This behavior may be changed in a
+ future release.
+
+
When you prepare a plan using the PL/Python module it is
automatically saved. Read the SPI documentation (
+
+
Restricted Environment
+
+ The current version of
PL/Python
+ functions as a trusted language only; access to the file system and
+ other local resources is disabled. Specifically,
+
PL/Python uses the Python restricted
+ execution environment, further restricts it to prevent the use of
+ the file open> call, and allows only modules from a
+ specific list to be imported. Presently, that list includes:
+ array, bisect, binascii, calendar, cmath, codecs, errno, marshal,
+ math, md5, mpz, operator, pcre, pickle, random, re, regex, sre,
+ sha, string, StringIO, struct, time, whrandom, and zlib.
+
+
+
readline feature. Read its documentation
for further details.)
-
- If you have the readline library installed but
-
psql does not seem to use it, you must
- make sure that
PostgreSQL's top-level
- configure script finds it.
- configure needs to find both the library
- libreadline.a (or a shared library equivalent)
- and the header files
- readline.h and history.h
- (or readline/readline.h and
- readline/history.h) in appropriate directories.
- If you have the library and header files installed in an obscure
- place you must tell configure about them, for
- example:
-$ ./configure --with-includes=/opt/gnu/include --with-libs=/opt/gnu/lib ...
-
- Then you have to recompile
psql (not
- necessarily the entire code tree).
-
-
- The
GNU readline library can be obtained from the
-
GNU project's
FTP server at
-
to turn this on, as it might expose programming mistakes. To use
this option, the macro USE_ASSERT_CHECKING
must be defined when
PostgreSQL is
- built (see the configure option
- <literal>--enable-cassert>). Note that
+ built (accomplished by the configure option
+ <option>--enable-cassert>). Note that
DEBUG_ASSERTIONS defaults to on if
PostgreSQL has been built with
assertions enabled.
syslog> is off. This option must be set at server
start.
- To use syslog>, the build of
-
PostgreSQL must be configured with
- the option.
-