| Server IP : 103.119.228.120 / Your IP : 18.217.161.27 Web Server : Apache System : Linux v8.techscape8.com 3.10.0-1160.119.1.el7.tuxcare.els2.x86_64 #1 SMP Mon Jul 15 12:09:18 UTC 2024 x86_64 User : nobody ( 99) PHP Version : 5.6.40 Disable Function : shell_exec,symlink,system,exec,proc_get_status,proc_nice,proc_terminate,define_syslog_variables,syslog,openlog,closelog,escapeshellcmd,passthru,ocinum cols,ini_alter,leak,listen,chgrp,apache_note,apache_setenv,debugger_on,debugger_off,ftp_exec,dl,dll,myshellexec,proc_open,socket_bind,proc_close,escapeshellarg,parse_ini_filepopen,fpassthru,exec,passthru,escapeshellarg,escapeshellcmd,proc_close,proc_open,ini_alter,popen,show_source,proc_nice,proc_terminate,proc_get_status,proc_close,pfsockopen,leak,apache_child_terminate,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,dl,symlink,shell_exec,system,dl,passthru,escapeshellarg,escapeshellcmd,myshellexec,c99_buff_prepare,c99_sess_put,fpassthru,getdisfunc,fx29exec,fx29exec2,is_windows,disp_freespace,fx29sh_getupdate,fx29_buff_prepare,fx29_sess_put,fx29shexit,fx29fsearch,fx29ftpbrutecheck,fx29sh_tools,fx29sh_about,milw0rm,imagez,sh_name,myshellexec,checkproxyhost,dosyayicek,c99_buff_prepare,c99_sess_put,c99getsource,c99sh_getupdate,c99fsearch,c99shexit,view_perms,posix_getpwuid,posix_getgrgid,posix_kill,parse_perms,parsesort,view_perms_color,set_encoder_input,ls_setcheckboxall,ls_reverse_all,rsg_read,rsg_glob,selfURL,dispsecinfo,unix2DosTime,addFile,system,get_users,view_size,DirFiles,DirFilesWide,DirPrintHTMLHeaders,GetFilesTotal,GetTitles,GetTimeTotal,GetMatchesCount,GetFileMatchesCount,GetResultFiles,fs_copy_dir,fs_copy_obj,fs_move_dir,fs_move_obj,fs_rmdir,SearchText,getmicrotime MySQL : ON | cURL : ON | WGET : ON | Perl : ON | Python : ON | Sudo : ON | Pkexec : ON Directory : /usr/share/doc/postgresql-9.2.24/html/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Database Access</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.2.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PL/Python - Python Procedural Language"
HREF="plpython.html"><LINK
REL="PREVIOUS"
TITLE="Trigger Functions"
HREF="plpython-trigger.html"><LINK
REL="NEXT"
TITLE="Explicit Subtransactions"
HREF="plpython-subtransaction.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2017-11-06T22:43:11"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.2.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Trigger Functions"
HREF="plpython-trigger.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpython.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 42. PL/Python - Python Procedural Language</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Explicit Subtransactions"
HREF="plpython-subtransaction.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PLPYTHON-DATABASE"
>42.7. Database Access</A
></H1
><P
> The PL/Python language module automatically imports a Python module
called <TT
CLASS="LITERAL"
>plpy</TT
>. The functions and constants in
this module are available to you in the Python code as
<TT
CLASS="LITERAL"
>plpy.<TT
CLASS="REPLACEABLE"
><I
>foo</I
></TT
></TT
>.
</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN59710"
>42.7.1. Database Access Functions</A
></H2
><P
> The <TT
CLASS="LITERAL"
>plpy</TT
> module provides several functions to execute
database commands:
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="LITERAL"
>plpy.<CODE
CLASS="FUNCTION"
>execute</CODE
>(<TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
> [, <TT
CLASS="REPLACEABLE"
><I
>max-rows</I
></TT
>])</TT
></DT
><DD
><P
> Calling <CODE
CLASS="FUNCTION"
>plpy.execute</CODE
> with a query string and an
optional row limit argument causes that query to be run and the result to
be returned in a result object.
</P
><P
> The result object emulates a list or dictionary object. The result
object can be accessed by row number and column name. For example:
</P><PRE
CLASS="PROGRAMLISTING"
>rv = plpy.execute("SELECT * FROM my_table", 5)</PRE
><P>
returns up to 5 rows from <TT
CLASS="LITERAL"
>my_table</TT
>. If
<TT
CLASS="LITERAL"
>my_table</TT
> has a column
<TT
CLASS="LITERAL"
>my_column</TT
>, it would be accessed as:
</P><PRE
CLASS="PROGRAMLISTING"
>foo = rv[i]["my_column"]</PRE
><P>
The number of rows returned can be obtained using the built-in
<CODE
CLASS="FUNCTION"
>len</CODE
> function.
</P
><P
> The result object has these additional methods:
<P
></P
></P><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="LITERAL"
><CODE
CLASS="FUNCTION"
>nrows</CODE
>()</TT
></DT
><DD
><P
> Returns the number of rows processed by the command. Note that this
is not necessarily the same as the number of rows returned. For
example, an <TT
CLASS="COMMAND"
>UPDATE</TT
> command will set this value but
won't return any rows (unless <TT
CLASS="LITERAL"
>RETURNING</TT
> is used).
</P
></DD
><DT
><TT
CLASS="LITERAL"
><CODE
CLASS="FUNCTION"
>status</CODE
>()</TT
></DT
><DD
><P
> The <CODE
CLASS="FUNCTION"
>SPI_execute()</CODE
> return value.
</P
></DD
><DT
><TT
CLASS="LITERAL"
><CODE
CLASS="FUNCTION"
>colnames</CODE
>()</TT
><BR><TT
CLASS="LITERAL"
><CODE
CLASS="FUNCTION"
>coltypes</CODE
>()</TT
><BR><TT
CLASS="LITERAL"
><CODE
CLASS="FUNCTION"
>coltypmods</CODE
>()</TT
></DT
><DD
><P
> Return a list of column names, list of column type OIDs, and list of
type-specific type modifiers for the columns, respectively.
</P
><P
> These methods raise an exception when called on a result object from
a command that did not produce a result set, e.g.,
<TT
CLASS="COMMAND"
>UPDATE</TT
> without <TT
CLASS="LITERAL"
>RETURNING</TT
>, or
<TT
CLASS="COMMAND"
>DROP TABLE</TT
>. But it is OK to use these methods on
a result set containing zero rows.
</P
></DD
></DL
></DIV
><P>
</P
><P
> The result object can be modified.
</P
><P
> Note that calling <TT
CLASS="LITERAL"
>plpy.execute</TT
> will cause the entire
result set to be read into memory. Only use that function when you are
sure that the result set will be relatively small. If you don't want to
risk excessive memory usage when fetching large results,
use <TT
CLASS="LITERAL"
>plpy.cursor</TT
> rather
than <TT
CLASS="LITERAL"
>plpy.execute</TT
>.
</P
></DD
><DT
><TT
CLASS="LITERAL"
>plpy.<CODE
CLASS="FUNCTION"
>prepare</CODE
>(<TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
> [, <TT
CLASS="REPLACEABLE"
><I
>argtypes</I
></TT
>])</TT
><BR><TT
CLASS="LITERAL"
>plpy.<CODE
CLASS="FUNCTION"
>execute</CODE
>(<TT
CLASS="REPLACEABLE"
><I
>plan</I
></TT
> [, <TT
CLASS="REPLACEABLE"
><I
>arguments</I
></TT
> [, <TT
CLASS="REPLACEABLE"
><I
>max-rows</I
></TT
>]])</TT
></DT
><DD
><P
>
<CODE
CLASS="FUNCTION"
>plpy.prepare</CODE
> prepares the execution plan for a
query. It is called with a query string and a list of parameter types,
if you have parameter references in the query. For example:
</P><PRE
CLASS="PROGRAMLISTING"
>plan = plpy.prepare("SELECT last_name FROM my_users WHERE first_name = $1", ["text"])</PRE
><P>
<TT
CLASS="LITERAL"
>text</TT
> is the type of the variable you will be passing
for <TT
CLASS="LITERAL"
>$1</TT
>. The second argument is optional if you don't
want to pass any parameters to the query.
</P
><P
> After preparing a statement, you use a variant of the
function <CODE
CLASS="FUNCTION"
>plpy.execute</CODE
> to run it:
</P><PRE
CLASS="PROGRAMLISTING"
>rv = plpy.execute(plan, ["name"], 5)</PRE
><P>
Pass the plan as the first argument (instead of the query string), and a
list of values to substitute into the query as the second argument. The
second argument is optional if the query does not expect any parameters.
The third argument is the optional row limit as before.
</P
><P
> Query parameters and result row fields are converted between PostgreSQL
and Python data types as described in <A
HREF="plpython-data.html"
>Section 42.3</A
>.
The exception is that composite types are currently not supported: They
will be rejected as query parameters and are converted to strings when
appearing in a query result. As a workaround for the latter problem, the
query can sometimes be rewritten so that the composite type result
appears as a result row rather than as a field of the result row.
Alternatively, the resulting string could be parsed apart by hand, but
this approach is not recommended because it is not future-proof.
</P
><P
> When you prepare a plan using the PL/Python module it is automatically
saved. Read the SPI documentation (<A
HREF="spi.html"
>Chapter 43</A
>) for a
description of what this means. In order to make effective use of this
across function calls one needs to use one of the persistent storage
dictionaries <TT
CLASS="LITERAL"
>SD</TT
> or <TT
CLASS="LITERAL"
>GD</TT
> (see
<A
HREF="plpython-sharing.html"
>Section 42.4</A
>). For example:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION usesavedplan() RETURNS trigger AS $$
if "plan" in SD:
plan = SD["plan"]
else:
plan = plpy.prepare("SELECT 1")
SD["plan"] = plan
# rest of function
$$ LANGUAGE plpythonu;</PRE
><P>
</P
></DD
><DT
><TT
CLASS="LITERAL"
>plpy.<CODE
CLASS="FUNCTION"
>cursor</CODE
>(<TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
>)</TT
><BR><TT
CLASS="LITERAL"
>plpy.<CODE
CLASS="FUNCTION"
>cursor</CODE
>(<TT
CLASS="REPLACEABLE"
><I
>plan</I
></TT
> [, <TT
CLASS="REPLACEABLE"
><I
>arguments</I
></TT
>])</TT
></DT
><DD
><P
> The <TT
CLASS="LITERAL"
>plpy.cursor</TT
> function accepts the same arguments
as <TT
CLASS="LITERAL"
>plpy.execute</TT
> (except for the row limit) and returns
a cursor object, which allows you to process large result sets in smaller
chunks. As with <TT
CLASS="LITERAL"
>plpy.execute</TT
>, either a query string
or a plan object along with a list of arguments can be used.
</P
><P
> The cursor object provides a <TT
CLASS="LITERAL"
>fetch</TT
> method that accepts
an integer parameter and returns a result object. Each time you
call <TT
CLASS="LITERAL"
>fetch</TT
>, the returned object will contain the next
batch of rows, never larger than the parameter value. Once all rows are
exhausted, <TT
CLASS="LITERAL"
>fetch</TT
> starts returning an empty result
object. Cursor objects also provide an
<A
HREF="http://docs.python.org/library/stdtypes.html#iterator-types"
TARGET="_top"
>iterator
interface</A
>, yielding one row at a time until all rows are
exhausted. Data fetched that way is not returned as result objects, but
rather as dictionaries, each dictionary corresponding to a single result
row.
</P
><P
> An example of two ways of processing data from a large table is:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION count_odd_iterator() RETURNS integer AS $$
odd = 0
for row in plpy.cursor("select num from largetable"):
if row['num'] % 2:
odd += 1
return odd
$$ LANGUAGE plpythonu;
CREATE FUNCTION count_odd_fetch(batch_size integer) RETURNS integer AS $$
odd = 0
cursor = plpy.cursor("select num from largetable")
while True:
rows = cursor.fetch(batch_size)
if not rows:
break
for row in rows:
if row['num'] % 2:
odd += 1
return odd
$$ LANGUAGE plpythonu;
CREATE FUNCTION count_odd_prepared() RETURNS integer AS $$
odd = 0
plan = plpy.prepare("select num from largetable where num % $1 <> 0", ["integer"])
rows = list(plpy.cursor(plan, [2]))
return len(rows)
$$ LANGUAGE plpythonu;</PRE
><P>
</P
><P
> Cursors are automatically disposed of. But if you want to explicitly
release all resources held by a cursor, use the <TT
CLASS="LITERAL"
>close</TT
>
method. Once closed, a cursor cannot be fetched from anymore.
</P
><DIV
CLASS="TIP"
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
> Do not confuse objects created by <TT
CLASS="LITERAL"
>plpy.cursor</TT
> with
DB-API cursors as defined by
the <A
HREF="http://www.python.org/dev/peps/pep-0249/"
TARGET="_top"
>Python
Database API specification</A
>. They don't have anything in common
except for the name.
</P
></BLOCKQUOTE
></DIV
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPYTHON-TRAPPING"
>42.7.2. Trapping Errors</A
></H2
><P
> Functions accessing the database might encounter errors, which
will cause them to abort and raise an exception. Both
<CODE
CLASS="FUNCTION"
>plpy.execute</CODE
> and
<CODE
CLASS="FUNCTION"
>plpy.prepare</CODE
> can raise an instance of a subclass of
<TT
CLASS="LITERAL"
>plpy.SPIError</TT
>, which by default will terminate
the function. This error can be handled just like any other
Python exception, by using the <TT
CLASS="LITERAL"
>try/except</TT
>
construct. For example:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION try_adding_joe() RETURNS text AS $$
try:
plpy.execute("INSERT INTO users(username) VALUES ('joe')")
except plpy.SPIError:
return "something went wrong"
else:
return "Joe added"
$$ LANGUAGE plpythonu;</PRE
><P>
</P
><P
> The actual class of the exception being raised corresponds to the
specific condition that caused the error. Refer
to <A
HREF="errcodes-appendix.html#ERRCODES-TABLE"
>Table A-1</A
> for a list of possible
conditions. The module
<TT
CLASS="LITERAL"
>plpy.spiexceptions</TT
> defines an exception class
for each <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> condition, deriving
their names from the condition name. For
instance, <TT
CLASS="LITERAL"
>division_by_zero</TT
>
becomes <TT
CLASS="LITERAL"
>DivisionByZero</TT
>, <TT
CLASS="LITERAL"
>unique_violation</TT
>
becomes <TT
CLASS="LITERAL"
>UniqueViolation</TT
>, <TT
CLASS="LITERAL"
>fdw_error</TT
>
becomes <TT
CLASS="LITERAL"
>FdwError</TT
>, and so on. Each of these
exception classes inherits from <TT
CLASS="LITERAL"
>SPIError</TT
>. This
separation makes it easier to handle specific errors, for
instance:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION insert_fraction(numerator int, denominator int) RETURNS text AS $$
from plpy import spiexceptions
try:
plan = plpy.prepare("INSERT INTO fractions (frac) VALUES ($1 / $2)", ["int", "int"])
plpy.execute(plan, [numerator, denominator])
except spiexceptions.DivisionByZero:
return "denominator cannot equal zero"
except spiexceptions.UniqueViolation:
return "already have that fraction"
except plpy.SPIError, e:
return "other error, SQLSTATE %s" % e.sqlstate
else:
return "fraction inserted"
$$ LANGUAGE plpythonu;</PRE
><P>
Note that because all exceptions from
the <TT
CLASS="LITERAL"
>plpy.spiexceptions</TT
> module inherit
from <TT
CLASS="LITERAL"
>SPIError</TT
>, an <TT
CLASS="LITERAL"
>except</TT
>
clause handling it will catch any database access error.
</P
><P
> As an alternative way of handling different error conditions, you
can catch the <TT
CLASS="LITERAL"
>SPIError</TT
> exception and determine
the specific error condition inside the <TT
CLASS="LITERAL"
>except</TT
>
block by looking at the <TT
CLASS="LITERAL"
>sqlstate</TT
> attribute of
the exception object. This attribute is a string value containing
the <SPAN
CLASS="QUOTE"
>"SQLSTATE"</SPAN
> error code. This approach provides
approximately the same functionality
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpython-trigger.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="plpython-subtransaction.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Trigger Functions</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="plpython.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Explicit Subtransactions</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>