On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
>
> > Localizing an individual element of %SIG works fine.
> > In C that's something like this (untested):
> >
> > hv = gv_fetchpv("
[I've included a summary of the thread and Bcc'd this to perl5-porters
for a sanity check. Please trim heavily when replying.]
On Thu, Aug 04, 2011 at 09:42:31AM -0400, Andrew Dunstan wrote:
>
> So doesn't this look like a bug in the perl module that sets the
> signal handler and doesn't restore
On Sat, Feb 12, 2011 at 02:17:12AM +0200, Alexey Klyukin wrote:
>
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
Given that encode_array_literal() encodes an _array_ as a literal,
I'd assume encode_
On Tue, Feb 08, 2011 at 09:40:38AM -0500, Andrew Dunstan wrote:
> On 02/03/2011 01:20 PM, Andrew Dunstan wrote:
> >
> >Well, the question seems to be whether or not it's a reasonable
> >price to pay. On the whole I'm inclined to think it is, especially
> >when it can be avoided by updating your cod
On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote:
> Hi,
>
> On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote:
>
> > I'm sorry I'm late to this party. I haven't been keeping up with
> > pgsql-hackers.
>
> Better late than never :)
>
&g
On Wed, Feb 02, 2011 at 12:10:59PM -0500, Andrew Dunstan wrote:
>
> On 02/02/2011 11:45 AM, Tim Bunce wrote:
> >>But why are we bothering to keep $prolog at
> >>all any more, if all we're going to pass it is&PL_sv_no all the
> >>time? Maybe we'll ha
I'm sorry I'm late to this party. I haven't been keeping up with pgsql-hackers.
I'd kind'a hoped that this functionality could be tied into extending
PL/Perl to handle named arguments. That way the perl variables
corresponding to the named arguments could be given references without
breaking any c
On Mon, Jan 31, 2011 at 02:22:37PM -0500, Andrew Dunstan wrote:
>
>
> On 01/15/2011 12:31 AM, Alex Hunsaker wrote:
> >On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> >>Changes:
> >>
> >>Sets the local $_TD via C instead of passing an extra argu
On Wed, Dec 08, 2010 at 09:21:05AM -0800, David E. Wheeler wrote:
> On Dec 8, 2010, at 9:14 AM, Tim Bunce wrote:
>
> >> Do you have any more improvements in the pipeline?
> >
> > I'd like to add $arrayref = decode_array_literal('{2,3}') and
> > ma
On Tue, Dec 07, 2010 at 10:00:28AM -0500, Andrew Dunstan wrote:
>
>
> On 12/07/2010 09:24 AM, Tim Bunce wrote:
> >Changes:
> >
> > Sets the local $_TD via C instead of passing an extra argument.
> > So functions no longer start with "our $_TD; local
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with "our $_TD; local $_TD = shift;"
Pre-extend stack for trigger arguments for slight performance gain.
Passes installcheck.
Tim.
diff --git a/src/pl/plperl/plperl.c b/src/pl/plper
[Sorry for the delay. I'd stopped checking the pgsql mailing lists.
Thanks to David Wheeler and Josh Berkus for the heads-up.]
On Sun, May 30, 2010 at 06:58:32PM -0400, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
&
On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > Why do the release notes say this, under plperl:
> > * PL/Perl subroutines are now given names (Tim Bunce)
> > This is for the use of profiling and code coverage tools. DIDN&
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Here's a patch that:
> > 1. adds wording like that to the docs.
> > 2. randomises the container package name (a simple and sound security
> > measure).
> > 3. requires Safe 2.2
On Wed, Mar 03, 2010 at 07:01:56PM -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
> >
> >>Well, we could put in similar weasel words I guess. But after
> >>all, Safe's very purpose is to provide a restricted execution
> >>environmen
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I encountered a core dump running PL/Perl installcheck with a very
> > recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
>
> > The cause is a subtle difference betw
I encountered a core dump running PL/Perl installcheck with a very
recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
The cause is a subtle difference between SvTYPE(sv) == SVt_RV and
SvROK(sv). The former is checking a low-level implementation detail
while the later is dire
On Tue, Mar 02, 2010 at 07:33:47PM -0500, Andrew Dunstan wrote:
>
> There appears to be some significant misunderstanding of what can be
> done effectively using the various *_init settings for plperl.
>
> In particular, some people have got an expectation that modules
> loaded in plperl.on_init
On Wed, Feb 17, 2010 at 10:30:03AM -0800, David E. Wheeler wrote:
> On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
>
> >> Yes, but if it's a variadic function, I suspect that it won't often be
> >> called with the same number of args. So you'd potentially e
Did this ever get turned into a formal bug report with a number?
Tim.
On Thu, Jan 14, 2010 at 07:39:09PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
>andrew=# SET SESSION plperl.use_strict = on;
>SET
>andrew=# SHOW
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
>
> >>> For varadic functions, separate plans are created and cached for each
> >>> distinct
> >>> number of arguments the function is call
On Tue, Feb 16, 2010 at 05:22:27PM -0500, Robert Haas wrote:
> > It's certainly been an interesting introduction to PostgreSQL
> > development!
>
> Hopefully we haven't scared you off - your work is definitely very
> much appreciated (and I at least hope to see you back for 9.1)!
Thanks Robert. T
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
>
> > p.s. One quick heads-up: David Wheeler has reported a possible issue
> > with Safe 2.21. I hope to investigate that tomorrow.
>
> Actually it'
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
> >>Robert Haas wrote:
> >>>We're down to 5 patches remaining, and 1 day remaining, so it's time
> >&g
On Tue, Feb 16, 2010 at 09:11:24AM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 4:08 AM, Tim Bunce wrote:
>
> From the docs:
>
> > Immediately after the function name, in parenthesis, a comma separated list
> > of
> > type names can be given.
On Mon, Feb 15, 2010 at 02:58:47PM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
>
> > I've not really looked the the DBD::Pg code much so this seemed like a
> > good excuse... It looks like the default is to call PQprepare() with
> &g
On Mon, Feb 15, 2010 at 11:52:01AM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
>
> > The signature doesn't just qualify the selection of the function,
> > it also ensures appropriate interpretation of the arguments.
> >
> &
On Mon, Feb 15, 2010 at 10:51:14AM +, Tim Bunce wrote:
> On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> > On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
> >
> > > I've appended the POD documentation and attached the (rough but working)
>
On Mon, Feb 15, 2010 at 10:42:15AM +, Richard Huxton wrote:
> On 15/02/10 10:32, Tim Bunce wrote:
> >On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> >>
> >>Is there any value in having a two-stage interface?
> >>
> >>$seq_fn =
so on_proc_exit will only be called if plperl_*_init() succeeds
(else there's a risk of on_proc_exit consuming all the exit hook slots)
- don't allow use of Safe version 2.21 as that's broken for PL/Perl.
Tim.
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
>
> > I've appended the POD documentation and attached the (rough but working)
> > test script.
> >
> > I plan to release the module to CPAN i
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> On 12/02/10 23:10, Tim Bunce wrote:
> >There was some discussion a few weeks ago about inter-stored-procedure
> >calling from PL/Perl.
>
> >I'd greatly appreciate any feedback.
>
> Looks gre
On Fri, Feb 12, 2010 at 07:57:15PM -0500, Andrew Dunstan wrote:
> Alex Hunsaker wrote:
> > Yes it could allow people who
> >can set the plperl.*_init functions to muck with the safe. As an
> >admin I could also do that by setting plperl.on_init and overloading
> >subs in the Safe namespace or swi
On Fri, Feb 12, 2010 at 02:30:37PM -0700, Alex Hunsaker wrote:
> On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan wrote:
> > Alex Hunsaker wrote:
>
> > and leave the rest for the next release, unless you can
> > convince me real fast that we're not opening a back door here. If we're
> > going to
On Fri, Feb 12, 2010 at 11:10:15PM +, Tim Bunce wrote:
> I've appended the POD documentation and attached the (rough but working)
> test script.
Oops. Here's the test script.
Tim.
create or replace function test_call() returns text language plperlu as $func$
use lib
There was some discussion a few weeks ago about inter-stored-procedure
calling from PL/Perl.
I thought I'd post the documentation (and tests) for a module I'm
working on to simplify calling SQL functions from PL/Perl.
Here are some real-world examples (not the best code, but genuine
use-cases):
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
[Sigh. This email, unlike the previous, actually includes the patch.]
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
version are in the docs, as I outlined in the previous message.
On Sun, Feb 07, 2010 at 08:25:33PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >This is the third update to the fourth of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >Changes in this patch:
> >
> >- Added
On Sat, Feb 06, 2010 at 10:38:00PM -0800, Josh Berkus wrote:
>
> Add on_trusted_init and on_untrusted_init to plperl
> Package namespace and Safe init cleanup for plperl
Alex Hunsaker has marked the latest version of both of those
as Ready for Committer.
Tim.
--
Sent via pgsql-hackers mailing
On Fri, Feb 05, 2010 at 09:19:26AM -0500, Bruce Momjian wrote:
> My son has brought to my attention that our current crop of Python
> client libraries is inadequate/confusing. I took a look myself, and
> asked on our IRC channel, and am now convinced this area needs
> attention.
>
> http://
This is the third update to the fourth of the patches to be split out
from the former 'plperl feature patch 1'.
Changes in this patch:
- Added plperl.on_plperl_init and plperl.on_plperlu_init GUCs
Both are PGC_SUSET
SPI functions are not available when the code is run.
Errors are dete
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
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 funct
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
On Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote:
> On Mon, Feb 1, 2010 at 03:58, Tim Bunce wrote:
> > On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> >
> >> plc_safe_ok.pl seems to loose its CVS $PostgreSQL$ keyword.
> >Probably a sli
On Mon, Feb 01, 2010 at 10:46:10AM -0500, Robert Haas wrote:
> On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce wrote:
> > p.s. If there is interest in defining a documented API (for DBAs to
> > control what gets loaded into Safe and shared with it) for *9.0*
> > then that could be
On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 16:16, Tim Bunce wrote:
> > This is an update to the final plperl patch in the series from me.
> >
> > Changes in the original patch:
>
> plc_safe_ok.pl seems to loose its CVS $Pos
This is an update to the final plperl patch in the series from me.
Changes in the original patch:
- Moved internal functions out of main:: namespace
into PostgreSQL::InServer and PostgreSQL::InServer::safe
- Restructured Safe compartment setup code
to generalize and separate the data fro
On Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 07:51, Tim Bunce wrote:
> > On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
> >
> >> Other than those really quite minor questions that are arguably me
> >> ni
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
On Fri, Jan 29, 2010 at 08:07:30PM -0700, Alex Hunsaker wrote:
> A couple of comments. *note* I have not tested this as a whole yet
> (due to rejects).
>
> in plc_perboot.pl
> +$funcsrc .= qq[ package main; undef *{'$name'}; *{'$name'} = sub {
> $BEGIN $prolog $src } ];
>
> Any thoughts on using
On Fri, Jan 29, 2010 at 09:10:48PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >This is an updated version of the third of the patches to be
> >split out from the former 'plperl feature patch 1'.
> >
> >It includes changes following discussions wit
This is an updated version of the third of the patches to be
split out from the former 'plperl feature patch 1'.
It includes changes following discussions with Tom Lane and others.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available
On Thu, Jan 28, 2010 at 07:49:37PM +, Tim Bunce wrote:
>
> I think I missed this because the Xcode compiler on Snow Leopard is
> fairly old (gcc 4.2.1).
For the record, gcc 4.2.1 does report the error. I'd missed it because
I'd done most of my builds with perl 5.
On Thu, Jan 28, 2010 at 11:02:23PM -0500, Andrew Dunstan wrote:
>
>
> Tim Bunce wrote:
> >This is an updated version of the third of the patches to be split out
> >from the former 'plperl feature patch 1'.
> >
> >It includes changes following discussio
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I think the only controversial change is this one:
>
> >> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> >> Both are PGC_USERSET.
> >> SPI functions
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Isn't it a security hole if on_trusted_init is USERSET? That means
> >> an unprivileged user can determine what will happen in plperlu.
> >> SUSET would be saner.
>
> > ITYM on_untrusted_i
On Thu, Jan 28, 2010 at 12:49:20PM -0500, Tom Lane wrote:
> Joe Conway writes:
> > I pull directly from CVS, not git, but in any case my line 1117 is
> > subref = newRV_inc((SV*)GvCVu((GV*)sub_glob));
> > so it appears to be the same
>
> >> What perl version are you using?
> >> What compile
Now the dust is settling on the on_perl_init patch I'd like to ask for
clarification on this next patch.
On Fri, Jan 15, 2010 at 12:35:06AM +0000, Tim Bunce wrote:
> This is the fourth of the patches to be split out from the former
> 'plperl feature patch 1'.
>
> Chan
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> >> An advantage of on_proc_exit from your end is that it should allow
> >> you to not have to try to prevent the END blocks f
This is an updated version of the third of the patches to be split out
from the former 'plperl feature patch 1'.
It includes changes following discussions with Tom Lane and others.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available
On Thu, Jan 28, 2010 at 06:31:19AM -0800, Joe Conway wrote:
> Last night I noted the following warning:
>
> plperl.c: In function ‘plperl_create_sub’:
>
> plperl.c:1117: warning: null argument where non-null required (argument 2)
The master branch of my git clone says line 1117 is:
subref =
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn't involve plperl at all. (Alternatively I coul
On Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> >> Really? We've found that gprof, for instance, doesn't exactly have
> >> "zero interaction with the rest o
On Wed, Jan 27, 2010 at 01:51:47PM -0800, David E. Wheeler wrote:
> On Jan 27, 2010, at 1:27 PM, Tim Bunce wrote:
>
> > Okay. I could change the callback code to ignore calls if
> > proc_exit_inprogress is false. So an abnormal shutdown via exit()
> > wouldn
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Indeed, AFAICS the major *point* of these additions is to allow people
> >> to insert unknown other functionality that is likely to interact
> >> with the rest of the backend; a prospect tha
On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> >> (In particular note that shutdown itself might be fired as an atexit
> >> callback, a move forced on us by exactly t
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> >> FWIW the atexit scares me to.
>
> > In what way, specifically?
>
> It runs too late, and too unpredictably, du
On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tim Bunce wrote:
> >> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
> >> SPI functions are not available when the code is run.
> >>
> >> - Added norm
On Wed, Jan 27, 2010 at 12:46:42AM -0700, Alex Hunsaker wrote:
> On Tue, Jan 26, 2010 at 23:14, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Tim Bunce wrote:
> >>> - Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
> >>> SPI functi
On Fri, Jan 15, 2010 at 04:02:02AM +, Tim Bunce wrote:
> This is the final plperl patch in the series from me.
>
> Changes in this patch:
>
> - Moved internal functions out of main:: namespace
> into PostgreSQL::InServer and PostgreSQL::InServer::safe
>
> - Restr
On Mon, Jan 25, 2010 at 11:09:12AM -0500, Andrew Dunstan wrote:
>
> Tim Bunce wrote:
> >
> >FYI I've an updated patch ready but I'll wait till the commitfest has
> >got 'closer' as there's a fair chance a further update will be needed
> >anyw
On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 23, 2010 at 16:16, Tim Bunce wrote:
> > On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> >> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> >> I'd vote for use warni
On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
> On Thu, Jan 14, 2010 at 09:07, Tim Bunce wrote:
> > - Allow (ineffective) use of 'require' in plperl
> > If the required module is not already loaded then it dies.
> > So "use strict;"
On Thu, Jan 21, 2010 at 07:55:09PM -0500, Andrew Dunstan wrote:
> Tom Lane wrote:
> >Andrew Dunstan writes:
> >>Jim Nasby wrote:
> >>>Why does warn; in plperl log as NOTICE in Postgres?
> >
> >>Where would you like the warning to go? This has been this way
> >>for nearly 5 years, it's not new (and
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and test the
patches, and ho
This is the final plperl patch in the series from me.
Changes in this patch:
- Moved internal functions out of main:: namespace
into PostgreSQL::InServer and PostgreSQL::InServer::safe
- Restructured Safe compartment setup code
to generalize and separate the data from the logic.
Neither
This is 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
Both are PGC_USERSET.
SPI functions are not available when the code is run.
Errors are detected and report
This is the third of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added plperl.on_perl_init GUC for DBA use (PGC_SIGHUP)
SPI functions are not available when the code is run.
- Added normal interpreter destruction behaviour
END blocks, if
On Thu, Jan 14, 2010 at 09:34:42AM -0800, David E. Wheeler wrote:
> On Jan 14, 2010, at 8:07 AM, Tim Bunce wrote:
>
> > - Stored procedure subs are now given names.
> >The names are not visible in ordinary use, but they make
> >tools like Devel::NYTProf and Devel::
This is the second of the patches to be split out from the former
'plperl feature patch 1'.
Changes in this patch:
- Allow (ineffective) use of 'require' in plperl
If the required module is not already loaded then it dies.
So "use strict;" now works in plperl.
- Pre-load the feature modu
This is the first of the patches to be split out from the former 'plperl
feature patch 1'.
Changes in this patch:
- Added utility functions: quote_literal, quote_nullable, quote_ident,
encode_bytea, decode_bytea, looks_like_number,
encode_array_literal, encode_array_constructor.
- Stored
On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
> On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas wrote:
> >>> I would strongly suggest to Tim that he rip the portions of this patch
> >>> that are related to this feature out and submit them separately so
> >>> that we can commit the unco
Thanks for all the feedback!
I'm going to try to summarize and address the issues raised.
(Meanwhile I've started spliting the patch into at least three parts,
per Andrew's suggestion: utility functions, the GUCs, the rest.)
* Long GUC values
I think the underlying assumption that they'll be l
On Sun, Jan 10, 2010 at 01:16:13AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Sat, Jan 09, 2010 at 11:16:18PM +0200, Peter Eisentraut wrote:
> >> What's the reason for the temp file here?
>
> > Defensive. If the text2macro.pl program fails/dies then you&#x
On Sat, Jan 09, 2010 at 11:49:22PM +, Tim Bunce wrote:
> On Sat, Jan 09, 2010 at 11:16:18PM +0200, Peter Eisentraut wrote:
> > On fre, 2010-01-08 at 12:46 +0000, Tim Bunce wrote:
> > > *** 45,50
> > > --- 45,55
> > >
> > &g
On Sat, Jan 09, 2010 at 11:16:18PM +0200, Peter Eisentraut wrote:
> On fre, 2010-01-08 at 12:46 +0000, Tim Bunce wrote:
> > *** 45,50
> > --- 45,55
> >
> > include $(top_srcdir)/src/Makefile.shlib
> >
> > + plperl.o: perlchunk
On Sat, Jan 09, 2010 at 02:17:27AM -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Andrew Dunstan wrote:
> > >
> > > Tim Bunce's recent patch has been mangled apparently by the list
> > > archives. He sent it as an attachment, and that's how I have it in
> > > my mailbox, so why isn't it
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
> On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce wrote:
> > I didn't get any significant feedback from the earlier draft so here's
> > the finished 'feature patch 1' for plperl. (This builds on my earlie
On Fri, Jan 08, 2010 at 09:47:01PM -0500, Andrew Dunstan wrote:
> Tim Bunce wrote:
> >
> >I see you've not commited it yet, so to help out I've attached
> >a new diff, over the current CVS head, with two minor changes:
> >
> >- Removed the test, as noted
On Mon, Jan 04, 2010 at 06:38:03PM -0500, Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> >>
> >>Yes. I believe the test is highlighting an existing problem: that plperl
> >>function in non-PG_UTF8 databases can't use regular expressions that
> >>require unicode character meta-data.
> >>
> >>Either
On Thu, Jan 07, 2010 at 05:45:08PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
> >> Is there any reason not to add .gitignore files into the repository?
>
> > I already find the .cvsignore files to be
I've a .git/info/exclude file I pulled from a link on the dev wiki.
Some of the changes I'm making create new files that ought to be added
to the excluded files. I can easily add them to my .git/info/exclude
file but it's much more work for me and others to spread those changes.
Is there any reas
On Wed, Jan 06, 2010 at 08:46:11PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
> >> On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
> >>> One of the things on my to-do list for today is to make config
On Wed, Jan 06, 2010 at 07:07:12PM -0500, Andrew Dunstan wrote:
>
> Alvaro Herrera wrote:
> >decibel wrote:
> >
> >>We've actually run into similar issues. Alvaro came up with a patch
> >>that fixes our specific issue, but I think he said there were some
> >>other cases that needed to be fixed as
I was investigating a bug in an 8.4.1 production system and distilled a
test case down to this:
CREATE OR REPLACE FUNCTION bar() RETURNS integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to exit(255)
spi_exec_query("inv
On Wed, Jan 06, 2010 at 11:41:46AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Next question: what do we do if a direct-called function calls
> > return_next()? That at least must surely take effect in the caller's
> > context - the callee won't have anywhere to stash the the results at
On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
> On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
>
> > One of the things on my to-do list for today is to make configure reject
> > Perl versions less than $TBD. I thought we had agreed a week or so back
> > that 5.8 was the lowest s
1 - 100 of 128 matches
Mail list logo
