Re: I propose killing PL/Tcl's "modules" infrastructure
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org, Jan Wieck <jan@wi3ck.info>
Date: 2017-02-27T20:42:26Z
Lists: pgsql-hackers
Attachments
- pltcl_start_proc-1.patch (text/x-diff) patch
Andrew Dunstan <andrew.dunstan@2ndquadrant.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
Commits
-
Invent start_proc parameters for PL/Tcl.
- 0d2b1f305dc7 10.0 landed
-
Remove PL/Tcl's "module" facility.
- 817f2a586342 10.0 landed
-
Remove all of the libpgtcl and pgtclsh files, including all references to
- 41fa9e9bae60 8.0.0 cited