Skip to content

Commit fcc02c2

Browse files
committed
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
1 parent 4c49488 commit fcc02c2

File tree

3 files changed

+59
-33
lines changed

3 files changed

+59
-33
lines changed

doc/src/sgml/plperl.sgml

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.54 2006/05/29 13:51:23 adunstan Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.55 2006/05/30 11:40:21 momjian Exp $ -->
22

33
<chapter id="plperl">
44
<title>PL/Perl - Perl Procedural Language</title>
@@ -17,6 +17,12 @@
1717
<ulink url="http://www.perl.com">Perl programming language</ulink>.
1818
</para>
1919

20+
<para> The usual advantage to using PL/Perl is that this allows use,
21+
within stored functions, of the manyfold <quote>string
22+
munging</quote> operators and functions available for Perl. Parsing
23+
complex strings may be be easier using Perl than it is with the
24+
string functions and control structures provided in PL/pgsql.</para>
25+
2026
<para>
2127
To install PL/Perl in a particular database, use
2228
<literal>createlang plperl <replaceable>dbname</></literal>.

doc/src/sgml/plpgsql.sgml

Lines changed: 28 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.89 2006/05/28 03:03:17 adunstan Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.90 2006/05/30 11:40:21 momjian Exp $ -->
22

33
<chapter id="plpgsql">
44
<title><application>PL/pgSQL</application> - <acronym>SQL</acronym> Procedural Language</title>
@@ -155,21 +155,36 @@ $$ LANGUAGE plpgsql;
155155

156156
<para>
157157
That means that your client application must send each query to
158-
the database server, wait for it to be processed, receive the
159-
results, do some computation, then send other queries to the
160-
server. All this incurs interprocess communication and may also
161-
incur network overhead if your client is on a different machine
162-
than the database server.
158+
the database server, wait for it to be processed, receive and
159+
process the results, do some computation, then send further
160+
queries to the server. All this incurs interprocess
161+
communication and will also incur network overhead if your client
162+
is on a different machine than the database server.
163163
</para>
164164

165165
<para>
166-
With <application>PL/pgSQL</application> you can group a block of computation and a
167-
series of queries <emphasis>inside</emphasis> the
168-
database server, thus having the power of a procedural
169-
language and the ease of use of SQL, but saving lots of
170-
time because you don't have the whole client/server
171-
communication overhead. This can make for a
172-
considerable performance increase.
166+
With <application>PL/pgSQL</application> you can group a block of
167+
computation and a series of queries <emphasis>inside</emphasis>
168+
the database server, thus having the power of a procedural
169+
language and the ease of use of SQL, but with considerable
170+
savings because you don't have the whole client/server
171+
communication overhead.
172+
</para>
173+
<itemizedlist>
174+
175+
<listitem><para> Elimination of additional round trips between
176+
client and server </para></listitem>
177+
178+
<listitem><para> Intermediate results that the client does not
179+
need do not need to be marshalled or transferred between server
180+
and client </para></listitem>
181+
182+
<listitem><para> There is no need for additional rounds of query
183+
parsing </para></listitem>
184+
185+
</itemizedlist>
186+
<para> This can allow for a considerable performance increase as
187+
compared to an application that does not use stored functions.
173188
</para>
174189

175190
<para>

doc/src/sgml/pltcl.sgml

Lines changed: 24 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.40 2006/05/27 20:24:16 adunstan Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/pltcl.sgml,v 2.41 2006/05/30 11:40:21 momjian Exp $ -->
22

33
<chapter id="pltcl">
44
<title>PL/Tcl - Tcl Procedural Language</title>
@@ -25,22 +25,27 @@
2525
<title>Overview</title>
2626

2727
<para>
28-
PL/Tcl offers most of the capabilities a function
29-
writer has in the C language, except for some restrictions.
28+
PL/Tcl offers most of the capabilities a function writer has in
29+
the C language, with a few restrictions, and with the addition of
30+
the powerful string processing libraries that are available for
31+
Tcl.
3032
</para>
3133
<para>
32-
The good restriction is that everything is executed in a safe
33-
Tcl interpreter. In addition to the limited command set of safe Tcl, only
34-
a few commands are available to access the database via SPI and to raise
35-
messages via <function>elog()</>. There is no way to access internals of the
36-
database server or to gain OS-level access under the permissions of the
37-
<productname>PostgreSQL</productname> server process, as a C function can do.
38-
Thus, any unprivileged database user may be
39-
permitted to use this language.
34+
One compelling <emphasis>good</emphasis> restriction is that
35+
everything is executed from within the safety of the context of a
36+
Tcl interpreter. In addition to the limited command set of safe
37+
Tcl, only a few commands are available to access the database via
38+
SPI and to raise messages via <function>elog()</>. PL/Tcl
39+
provides no way to access internals of the database server or to
40+
gain OS-level access under the permissions of the
41+
<productname>PostgreSQL</productname> server process, as a C
42+
function can do. Thus, unprivileged database users may be trusted
43+
to use this language; it does not give them unlimited authority.
4044
</para>
4145
<para>
42-
The other, implementation restriction is that Tcl functions cannot
43-
be used to create input/output functions for new data types.
46+
The other notable implementation restriction is that Tcl functions
47+
may not be used to create input/output functions for new data
48+
types.
4449
</para>
4550
<para>
4651
Sometimes it is desirable to write Tcl functions that are not restricted
@@ -55,12 +60,12 @@
5560
a user logged in as the database administrator.
5661
</para>
5762
<para>
58-
The shared object for the <application>PL/Tcl</> and <application>PL/TclU</> call handlers is
59-
automatically built and installed in the
60-
<productname>PostgreSQL</productname>
61-
library directory if Tcl support is specified
62-
in the configuration step of the installation procedure. To install
63-
<application>PL/Tcl</> and/or <application>PL/TclU</> in a particular database, use the
63+
The shared object code for the <application>PL/Tcl</> and
64+
<application>PL/TclU</> call handlers is automatically built and
65+
installed in the <productname>PostgreSQL</productname> library
66+
directory if Tcl support is specified in the configuration step of
67+
the installation procedure. To install <application>PL/Tcl</>
68+
and/or <application>PL/TclU</> in a particular database, use the
6469
<command>createlang</command> program, for example
6570
<literal>createlang pltcl <replaceable>dbname</></literal> or
6671
<literal>createlang pltclu <replaceable>dbname</></literal>.

0 commit comments

Comments
 (0)