Re: I propose killing PL/Tcl's "modules" infrastructure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Jan Wieck <jan(at)wi3ck(dot)info>
Subject: Re: I propose killing PL/Tcl's "modules" infrastructure
Date: 2017-02-27 20:42:26
Message-ID: 21254.1488228146@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 02/26/2017 02:54 PM, Tom Lane wrote:
>> * I'm not terribly comfortable about what the permissions levels of the
>> GUCs ought to be.

> plperl's on_plperl_init and on_plperlu_init settings are both SUSET.
> In practice with PLv8 this is usually set in the config file in my
> experience.

Ah, I'd forgotten about that precedent. Being consistent with that seems
like a good thing --- and I agree with your point that this would likely
usually be set in postgresql.conf anyway, making the issue rather moot.

I noticed also that the precedent of plperl is that if the init code
fails, we give up on use of that interpreter, and try again to run
the init code if plperl is used again. This is different from what
I had in my draft spec but it probably is a better definition; without
it, people might find themselves running in Tcl interpreters that do
not behave as intended.

In sum, then, PFA a patch that adds these GUCs. They're still function
names but otherwise the details are closer to what plperl does.

regards, tom lane

Attachment Content-Type Size
pltcl_start_proc-1.patch text/x-diff 16.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-02-27 20:52:30 Re: make async slave to wait for lsn to be replayed
Previous Message Bruce Momjian 2017-02-27 20:29:16 Re: REINDEX CONCURRENTLY 2.0