1
0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00

Invent start_proc parameters for PL/Tcl.

Define GUCs pltcl.start_proc and pltclu.start_proc.  When set to a
nonempty value at the time a new Tcl interpreter is created, the
parameterless pltcl or pltclu function named by the GUC is called to
allow user-controlled initialization to occur within the interpreter.
This is modeled on plv8's start_proc parameter, and also has much in
common with plperl's on_init feature.  It allows users to fully
replace the "modules" feature that was removed in commit 817f2a586.

Since an initializer function could subvert later Tcl code in nearly
arbitrary ways, mark both GUCs as SUSET for now.  It would be nice
to find a way to relax that someday; but the corresponding GUCs in
plperl are also SUSET, and there's not been much complaint.

Discussion: https://postgr.es/m/22067.1488046447@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2017-03-07 12:40:44 -05:00
parent 03cf221934
commit 0d2b1f305d
5 changed files with 286 additions and 9 deletions

View File

@@ -902,6 +902,80 @@ if {[catch { spi_exec $sql_command }]} {
</para>
</sect1>
<sect1 id="pltcl-config">
<title>PL/Tcl Configuration</title>
<para>
This section lists configuration parameters that
affect <application>PL/Tcl</>.
</para>
<variablelist>
<varlistentry id="guc-pltcl-start-proc" xreflabel="pltcl.start_proc">
<term>
<varname>pltcl.start_proc</varname> (<type>string</type>)
<indexterm>
<primary><varname>pltcl.start_proc</> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
This parameter, if set to a nonempty string, specifies the name
(possibly schema-qualified) of a parameterless PL/Tcl function that
is to be executed whenever a new Tcl interpreter is created for
PL/Tcl. Such a function can perform per-session initialization, such
as loading additional Tcl code. A new Tcl interpreter is created
when a PL/Tcl function is first executed in a database session, or
when an additional interpreter has to be created because a PL/Tcl
function is called by a new SQL role.
</para>
<para>
The referenced function must be written in the <literal>pltcl</>
language, and must not be marked <literal>SECURITY DEFINER</>.
(These restrictions ensure that it runs in the interpreter it's
supposed to initialize.) The current user must have permission to
call it, too.
</para>
<para>
If the function fails with an error it will abort the function call
that caused the new interpreter to be created and propagate out to
the calling query, causing the current transaction or subtransaction
to be aborted. Any actions already done within Tcl won't be undone;
however, that interpreter won't be used again. If the language is
used again the initialization will be attempted again within a fresh
Tcl interpreter.
</para>
<para>
Only superusers can change this setting. Although this setting
can be changed within a session, such changes will not affect Tcl
interpreters that have already been created.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-pltclu-start-proc" xreflabel="pltclu.start_proc">
<term>
<varname>pltclu.start_proc</varname> (<type>string</type>)
<indexterm>
<primary><varname>pltclu.start_proc</> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
This parameter is exactly like <varname>pltcl.start_proc</varname>,
except that it applies to PL/TclU. The referenced function must
be written in the <literal>pltclu</> language.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="pltcl-procnames">
<title>Tcl Procedure Names</title>