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
> the above, and errors
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
> quite confused as to where n
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 fro
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 usually set in the config file in
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 trojan-
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 usability fail to me. I'm not sure
> how bad the s
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
> there's a separate risk of
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 pltclu.start_proc, which default
to empty strings
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
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
>>> cleaner to provide a feature similar
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 describe that could
>> be used for
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
>>> its currently very sad state.
"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 PL/Tcl as a whole. It's
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 right answer is just to
>> remov
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 evi
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 c
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 that).
17 matches
Mail list logo
