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 |
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 |