On Fri, Feb 12, 2010 at 8:56 AM, Andrew Dunstan wrote:
> There is documentation in Tim's patch I am working on right now. I don't
> think anything else is needed.
Cool.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Fri, Feb 12, 2010 at 5:40 AM, Tim Bunce wrote:
> What happens to patches marked 'ready for committer' after the
> commitfest ends?
We talk about it and figure out what to do. It'll be some combination
of (1) last-minute commits, (2) postponing things to 9.1, and (3)
rejecting things we don't
Robert Haas wrote:
The discussion on this seems to have died off. Andrew, do you have
something you're planning to commit for this? I think we're kind of
down to the level of bikeshedding here...
There is documentation in Tim's patch I am working on right now. I don't
think anything e
Tim Bunce wrote:
That updated patch is in the commitfest
https://commitfest.postgresql.org/action/patch_view?id=271
>From talking to Andrew via IM I understand he's very busy, and also that
he'll be traveling on Sunday and Monday.
I certainly hope he can commit this patch today (along with th
On Fri, Feb 12, 2010 at 12:22:28AM -0500, Robert Haas wrote:
> On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote:
> > Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>
> >>> %_SHARED has been around for several years now, and if there are genuine
> >>> security concerns about it ISTM they would
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>
>>>
>>> %_SHARED has been around for several years now, and if there are genuine
>>> security concerns about it ISTM they would apply today, regardless of these
>>> patches.
>>>
>>
>> Yes.
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote:
>> What I was actually wondering about, however, is the extent to which
>> the semantics of Perl code could be changed from an on_init hook ---
>> is there any equivalent of changing search_path or otherwise creating
>> trojan-horse code that m
Tom Lane wrote:
Andrew Dunstan writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of
these patches.
Yes. I am not at all happy about inserting nonstandard permissions
checks into GUC a
On Wed, Feb 3, 2010 at 2:38 PM, Tim Bunce wrote:
>> What I was actually wondering about, however, is the extent to which
>> the semantics of Perl code could be changed from an on_init hook ---
>> is there any equivalent of changing search_path or otherwise creating
>> trojan-horse code that might
On Wed, Feb 03, 2010 at 02:04:47PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > %_SHARED has been around for several years now, and if there are genuine
> > security concerns about it ISTM they would apply today, regardless of
> > these patches.
>
> Yes. I am not at all happy about inse
Alex Hunsaker writes:
> On Wed, Feb 3, 2010 at 12:04, Tom Lane wrote:
>> Yes. Â I am not at all happy about inserting nonstandard permissions
>> checks into GUC assign hooks
> I think Tims solution is just to check in plperl.c right before we
> eval it so not at SET time.
Well, that would be *c
On Wed, Feb 3, 2010 at 12:04, Tom Lane wrote:
> Andrew Dunstan writes:
>> %_SHARED has been around for several years now, and if there are genuine
>> security concerns about it ISTM they would apply today, regardless of
>> these patches.
>
> Yes. I am not at all happy about inserting nonstandard
On Wed, Feb 3, 2010 at 1:49 PM, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker wrote:
>> On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
>>> Tim Bunce writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functionc
On Feb 3, 2010, at 11:04 AM, Tom Lane wrote:
> What I was actually wondering about, however, is the extent to which
> the semantics of Perl code could be changed from an on_init hook ---
> is there any equivalent of changing search_path or otherwise creating
> trojan-horse code that might be execu
Andrew Dunstan writes:
> %_SHARED has been around for several years now, and if there are genuine
> security concerns about it ISTM they would apply today, regardless of
> these patches.
Yes. I am not at all happy about inserting nonstandard permissions
checks into GUC assign hooks --- they ar
Tom Lane wrote:
Tim Bunce writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you proposing to check, and where, and what do you
think that will fi
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
>> Tim Bunce writes:
>>> I do see a need for a GRANT check and I'm adding one now (based on
>>> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
>>> on IRC for the pointer).
>
On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
> Tim Bunce writes:
>> I do see a need for a GRANT check and I'm adding one now (based on
>> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
>> on IRC for the pointer).
>
> What exactly are you proposing to check, and where, and
Tim Bunce writes:
> I do see a need for a GRANT check and I'm adding one now (based on
> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
> on IRC for the pointer).
What exactly are you proposing to check, and where, and what do you
think that will fix?
If the concern is th
On Wed, Feb 3, 2010 at 10:56, Tim Bunce wrote:
> On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
>> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> >>
>> >>
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>
> >> > SPI functions are not available when the code is r
On Feb 3, 2010, at 9:21 AM, Alex Hunsaker wrote:
>>> plperl.on_init - run on interpreter creation
>>> plperl.on_plperl_init - run when then specialized for plperl
>>> plperl.on_plperlu_init - run when then specialized for plperlu
>>
>> Hrm, I think I agree with Tom that we
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> If we're going to bikeshed the names, I'd suggest:
>>
>> plperl.on_init - run on interpreter creation
>> plperl.o
On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>
>> > SPI functions are not available when the code is run.
>>
>> Hrm, we might want to stick why in the docs or as a comment som
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>
> > SPI functions are not available when the code is run.
>
> Hrm, we might want to stick why in the docs or as a comment somewhere.
> I think this was the main concern?
>
> * W
Robert Haas writes:
> On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker wrote:
>> Hey! I don't think were quite to that nasty B word yet :) I would
>> argue that treating plperl and plperlu as the same language just
>> because it shares the same code is a mistake. But I hate the idea of
>> two cust
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker wrote:
> Hey! I don't think were quite to that nasty B word yet :) I would
> argue that treating plperl and plperlu as the same language just
> because it shares the same code is a mistake. But I hate the idea of
> two custom_variable_classes for plp
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan wrote:
>
>
> Alex Hunsaker wrote:
>
> Well its already in.
>
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
>>>
>>> I can't sp
Alex Hunsaker wrote:
Well its already in.
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
I can't speak for its virtue, maybe Tim, Andrew?
plperl.on_perl_init runs when t
On Wed, Feb 3, 2010 at 00:46, Alex Hunsaker wrote:
> On Tue, Feb 2, 2010 at 22:50, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
Alex Hunsaker writes:
> Yeah the both is gross. How about:
> plperl.on_plperl_init
> plperl.on_plperlu
On Tue, Feb 2, 2010 at 22:50, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>> Alex Hunsaker writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
plperl.on_init ?
>> Well its already in.
>
> Wel
On Wednesday, February 3, 2010, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>>> Alex Hunsaker writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
plperl.on_init ?
>>>
>>> I like the first two.
Alex Hunsaker writes:
> On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> Yeah the both is gross. Â How about:
>>> plperl.on_plperl_init
>>> plperl.on_plperlu_init
>>> plperl.on_init ?
>>
>> I like the first two. Â The problem of selecting a good name for the
>> third o
On Tue, Feb 2, 2010 at 21:38, Tom Lane wrote:
> Alex Hunsaker writes:
>> Yeah the both is gross. How about:
>> plperl.on_plperl_init
>> plperl.on_plperlu_init
>> plperl.on_init ?
>
> I like the first two. The problem of selecting a good name for the
> third one is easily solved: don't have it.
Alex Hunsaker writes:
> Yeah the both is gross. How about:
> plperl.on_plperl_init
> plperl.on_plperlu_init
> plperl.on_init ?
I like the first two. The problem of selecting a good name for the
third one is easily solved: don't have it. What would it be except
a headache and a likely security
On Tue, Feb 2, 2010 at 20:46, Robert Haas wrote:
> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
>> On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
This is an update the fourth of the patches to be split out from the
form
On Tue, Feb 2, 2010 at 10:51 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
>> > On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> >>> This is an update the fourth of the patch
Robert Haas escribió:
> On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
> > On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>> This is an update the fourth of the patches to be split out from the
> >>> former 'plperl feature patch
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas wrote:
> On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>> This is an update the fourth of the patches to be split out from the
>>> former 'plperl feature patch 1'.
>>>
>>> Changes in this pat
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> This is an update the fourth of the patches to be split out from the
>> former 'plperl feature patch 1'.
>>
>> Changes in this patch:
>>
>> - Adds plperl.on_trusted_init and plperl.on_untrus
On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> This is an update the fourth of the patches to be split out from the
> former 'plperl feature patch 1'.
>
> Changes in this patch:
>
> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> on_trusted_init is PGC_USERSET, on_untrusted
This is an update the fourth of the patches to be split out from the
former 'plperl feature patch 1'.
Changes in this patch:
- Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
on_trusted_init is PGC_USERSET, on_untrusted_init is PGC_SUSET
SPI functions are not available when
42 matches
Mail list logo
