Update PL documentation:

An article at WebProNews quoted from the PG docs as to the merits of
stored procedures.  I have added a bit more material on their merits,
as well as making a few changes to improve the introductions to
PL/Perl and PL/Tcl.

Chris Browne
This commit is contained in:
Bruce Momjian 2006-05-30 11:40:21 +00:00
parent 4c494889a6
commit fcc02c20fc
3 changed files with 59 additions and 33 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.54 2006/05/29 13:51:23 adunstan Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.55 2006/05/30 11:40:21 momjian Exp $ -->
<chapter id="plperl"> <chapter id="plperl">
<title>PL/Perl - Perl Procedural Language</title> <title>PL/Perl - Perl Procedural Language</title>
@ -17,6 +17,12 @@
<ulink url="http://www.perl.com">Perl programming language</ulink>. <ulink url="http://www.perl.com">Perl programming language</ulink>.
</para> </para>
<para> The usual advantage to using PL/Perl is that this allows use,
within stored functions, of the manyfold <quote>string
munging</quote> operators and functions available for Perl. Parsing
complex strings may be be easier using Perl than it is with the
string functions and control structures provided in PL/pgsql.</para>
<para> <para>
To install PL/Perl in a particular database, use To install PL/Perl in a particular database, use
<literal>createlang plperl <replaceable>dbname</></literal>. <literal>createlang plperl <replaceable>dbname</></literal>.

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.89 2006/05/28 03:03:17 adunstan Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.90 2006/05/30 11:40:21 momjian Exp $ -->
<chapter id="plpgsql"> <chapter id="plpgsql">
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title> <title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
@ -155,21 +155,36 @@ $$ LANGUAGE plpgsql;
<para> <para>
That means that your client application must send each query to That means that your client application must send each query to
the database server, wait for it to be processed, receive the the database server, wait for it to be processed, receive and
results, do some computation, then send other queries to the process the results, do some computation, then send further
server. All this incurs interprocess communication and may also queries to the server. All this incurs interprocess
incur network overhead if your client is on a different machine communication and will also incur network overhead if your client
than the database server. is on a different machine than the database server.
</para> </para>
<para> <para>
With <application>PL/pgSQL</application> you can group a block of computation and a With <application>PL/pgSQL</application> you can group a block of
series of queries <emphasis>inside</emphasis> the computation and a series of queries <emphasis>inside</emphasis>
database server, thus having the power of a procedural the database server, thus having the power of a procedural
language and the ease of use of SQL, but saving lots of language and the ease of use of SQL, but with considerable
time because you don't have the whole client/server savings because you don't have the whole client/server
communication overhead. This can make for a communication overhead.
considerable performance increase. </para>
<itemizedlist>
<listitem><para> Elimination of additional round trips between
client and server </para></listitem>
<listitem><para> Intermediate results that the client does not
need do not need to be marshalled or transferred between server
and client </para></listitem>
<listitem><para> There is no need for additional rounds of query
parsing </para></listitem>
</itemizedlist>
<para> This can allow for a considerable performance increase as
compared to an application that does not use stored functions.
</para> </para>
<para> <para>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.40 2006/05/27 20:24:16 adunstan Exp $ --> <!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.41 2006/05/30 11:40:21 momjian Exp $ -->
<chapter id="pltcl"> <chapter id="pltcl">
<title>PL/Tcl - Tcl Procedural Language</title> <title>PL/Tcl - Tcl Procedural Language</title>
@ -25,22 +25,27 @@
<title>Overview</title> <title>Overview</title>
<para> <para>
PL/Tcl offers most of the capabilities a function PL/Tcl offers most of the capabilities a function writer has in
writer has in the C language, except for some restrictions. the C language, with a few restrictions, and with the addition of
the powerful string processing libraries that are available for
Tcl.
</para> </para>
<para> <para>
The good restriction is that everything is executed in a safe One compelling <emphasis>good</emphasis> restriction is that
Tcl interpreter. In addition to the limited command set of safe Tcl, only everything is executed from within the safety of the context of a
a few commands are available to access the database via SPI and to raise Tcl interpreter. In addition to the limited command set of safe
messages via <function>elog()</>. There is no way to access internals of the Tcl, only a few commands are available to access the database via
database server or to gain OS-level access under the permissions of the SPI and to raise messages via <function>elog()</>. PL/Tcl
<productname>PostgreSQL</productname> server process, as a C function can do. provides no way to access internals of the database server or to
Thus, any unprivileged database user may be gain OS-level access under the permissions of the
permitted to use this language. <productname>PostgreSQL</productname> server process, as a C
function can do. Thus, unprivileged database users may be trusted
to use this language; it does not give them unlimited authority.
</para> </para>
<para> <para>
The other, implementation restriction is that Tcl functions cannot The other notable implementation restriction is that Tcl functions
be used to create input/output functions for new data types. may not be used to create input/output functions for new data
types.
</para> </para>
<para> <para>
Sometimes it is desirable to write Tcl functions that are not restricted Sometimes it is desirable to write Tcl functions that are not restricted
@ -55,12 +60,12 @@
a user logged in as the database administrator. a user logged in as the database administrator.
</para> </para>
<para> <para>
The shared object for the <application>PL/Tcl</> and <application>PL/TclU</> call handlers is The shared object code for the <application>PL/Tcl</> and
automatically built and installed in the <application>PL/TclU</> call handlers is automatically built and
<productname>PostgreSQL</productname> installed in the <productname>PostgreSQL</productname> library
library directory if Tcl support is specified directory if Tcl support is specified in the configuration step of
in the configuration step of the installation procedure. To install the installation procedure. To install <application>PL/Tcl</>
<application>PL/Tcl</> and/or <application>PL/TclU</> in a particular database, use the and/or <application>PL/TclU</> in a particular database, use the
<command>createlang</command> program, for example <command>createlang</command> program, for example
<literal>createlang pltcl <replaceable>dbname</></literal> or <literal>createlang pltcl <replaceable>dbname</></literal> or
<literal>createlang pltclu <replaceable>dbname</></literal>. <literal>createlang pltclu <replaceable>dbname</></literal>.