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

2017-03-04 Thread Robert Haas
On Thu, Mar 2, 2017 at 11:29 PM, Tom Lane wrote: > After thinking about that for awhile, it seemed like the most useful thing > to do is to set up an errcontext callback that will be active throughout > execution of the start_proc. That will cover both setup failures like >

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

2017-03-02 Thread Tom Lane
Jim Nasby writes: > On 2/27/17 2:42 PM, Tom Lane wrote: >> + SET pltcl.start_proc = 'no_such_function'; >> + select tcl_int4add(1, 2); >> + ERROR: function no_such_function() does not exist > Can the error message be more explicit somehow? Otherwise people will be >

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

2017-03-01 Thread Jim Nasby
On 2/27/17 2:42 PM, Tom Lane wrote: + SET pltcl.start_proc = 'no_such_function'; + select tcl_int4add(1, 2); + ERROR: function no_such_function() does not exist Can the error message be more explicit somehow? Otherwise people will be quite confused as to where no_such_function() is coming

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

2017-02-27 Thread Tom Lane
Andrew Dunstan 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

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

2017-02-27 Thread Andrew Dunstan
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. The call permissions check means that you can't use > either GUC to call a function you couldn't have called anyway. However > there's a separate risk of

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

2017-02-27 Thread Tom Lane
Robert Haas writes: > On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane wrote: >> * I'm not terribly comfortable about what the permissions levels of the >> GUCs ought to be. ... Maybe we'd better make them both SUSET. > Making them SUSET sounds like a

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

2017-02-26 Thread Robert Haas
On Mon, Feb 27, 2017 at 1:24 AM, Tom Lane wrote: > * I'm not terribly comfortable about what the permissions levels of the > GUCs ought to be. The call permissions check means that you can't use > either GUC to call a function you couldn't have called anyway. However >

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

2017-02-26 Thread Tom Lane
Andrew Dunstan writes: > [ we should borrow plv8's start_proc idea for pltcl ] So after thinking about this for awhile, I propose the following concrete spec for replacing pltcl's autoload-unknown behavior: * Invent two GUCs, pltcl.start_proc and

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

2017-02-26 Thread Tom Lane
I wrote: > Now, we could try to fix this bug, and add the regression test coverage > that the code clearly lacks, and upgrade the documentation about it from > its currently very sad state. But I think the right answer is just to > remove the feature altogether. BTW, I tried to poke into what it

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

2017-02-25 Thread Andrew Dunstan
On 02/25/2017 02:21 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 02/25/2017 01:44 PM, Tom Lane wrote: >>> Yeah, the only part that's even a bit hard to replicate in userland is >>> initializing the autoloading mechanism in each session. It would be >>>

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

2017-02-25 Thread Tom Lane
Andrew Dunstan writes: > On 02/25/2017 01:44 PM, Tom Lane wrote: >> Yeah, the only part that's even a bit hard to replicate in userland is >> initializing the autoloading mechanism in each session. It would be >> cleaner to provide a feature similar to what you

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

2017-02-25 Thread Andrew Dunstan
On 02/25/2017 01:44 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 02/25/2017 01:14 PM, Tom Lane wrote: >>> Now, we could try to fix this bug, and add the regression test coverage >>> that the code clearly lacks, and upgrade the documentation about it from

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

2017-02-25 Thread Tom Lane
"Joshua D. Drake" writes: > I don't see a reason to keep pl/tcl in core at all so ripping out the > functionality seems the least disruptive and perhaps even a deprecation > of the PL (at least from a core perspective) in v10. I'm not in any hurry to remove or deprecate

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

2017-02-25 Thread Tom Lane
Andrew Dunstan writes: > On 02/25/2017 01:14 PM, Tom Lane wrote: >> Now, we could try to fix this bug, and add the regression test coverage >> that the code clearly lacks, and upgrade the documentation about it from >> its currently very sad state. But I think the

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

2017-02-25 Thread Joshua D. Drake
On 02/25/2017 10:14 AM, Tom Lane wrote: Now, we could try to fix this bug, and add the regression test coverage that the code clearly lacks, and upgrade the documentation about it from its currently very sad state. But I think the right answer is just to remove the feature altogether. It's

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

2017-02-25 Thread Andrew Dunstan
On 02/25/2017 01:14 PM, Tom Lane wrote: > Over in > https://www.postgresql.org/message-id/alpine.DEB.2.11.1702251701030.3920@Sandal.Woodpecker > it's pointed out that pltcl_loadmod was never updated for the switch > to standard_conforming_strings (and the patch proposed there doesn't > begin to

[HACKERS] I propose killing PL/Tcl's "modules" infrastructure

2017-02-25 Thread Tom Lane
Over in https://www.postgresql.org/message-id/alpine.DEB.2.11.1702251701030.3920@Sandal.Woodpecker it's pointed out that pltcl_loadmod was never updated for the switch to standard_conforming_strings (and the patch proposed there doesn't begin to cover all the places that would need fixed for