On Fri, Feb 12, 2010 at 12:22:28AM -0500, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns
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
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
On Fri, Feb 12, 2010 at 5:40 AM, Tim Bunce tim.bu...@pobox.com 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)
On Fri, Feb 12, 2010 at 8:56 AM, Andrew Dunstan and...@dunslane.net 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
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan and...@dunslane.net wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Wed, Feb 3, 2010 at 00:46, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 2, 2010 at 22:50, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both
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
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan and...@dunslane.net 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 speak for its virtue,
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker bada...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker bada...@gmail.com 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.
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com 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
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
SPI functions are not available when the code is run.
Hrm, we might want to stick why in
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com 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
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 should not
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
SPI functions are not
On Wed, Feb 3, 2010 at 10:56, Tim Bunce tim.bu...@pobox.com wrote:
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
On Wed, Feb 3, 2010 at 09:31, Tim Bunce tim.bu...@pobox.com wrote:
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 08:49,
Tim Bunce tim.bu...@pobox.com 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
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com 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
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com 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
Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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
Andrew Dunstan and...@dunslane.net 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
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 executed
On Wed, Feb 3, 2010 at 1:49 PM, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker bada...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:28, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com writes:
I do see a need for a GRANT check and I'm adding
On Wed, Feb 3, 2010 at 12:04, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
Alex Hunsaker bada...@gmail.com writes:
On Wed, Feb 3, 2010 at 12:04, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Feb 03, 2010 at 02:04:47PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Wed, Feb 3, 2010 at 2:38 PM, Tim Bunce tim.bu...@pobox.com 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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 6:41 PM, Andrew Dunstan and...@dunslane.net 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
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com 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 Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com 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
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
This is an update the fourth of the patches to be split out from the
former
Robert Haas escribió:
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
This is an update the fourth of the patches to be split
On Tue, Feb 2, 2010 at 10:51 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce
On Tue, Feb 2, 2010 at 20:46, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 2, 2010 at 10:42 PM, Alex Hunsaker bada...@gmail.com wrote:
On Sat, Jan 30, 2010 at 08:49, Tim Bunce tim.bu...@pobox.com wrote:
This is
Alex Hunsaker bada...@gmail.com 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
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com 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
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com 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
On Wednesday, February 3, 2010, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
On Tue, Feb 2, 2010 at 22:50, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
On Tue, Feb 2, 2010 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
Yeah the both is gross. How about:
plperl.on_plperl_init
plperl.on_plperlu_init
41 matches
Mail list logo
