On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
On Sun, Aug 7, 2011 at 17:06, Tim Bunce tim.bu...@pobox.com wrote:
Localizing an individual element of %SIG works fine.
In C that's something like this (untested):
hv = gv_fetchpv(SIG, 0, SVt_PVHV);
keysv = ...SV
[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
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 code, which
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 isPL_sv_no all the
time? Maybe we'll have a use for it in the future, but right now we
don't
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 :)
I'd kind'a hoped that this functionality could be tied
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 Buncetim.bu...@pobox.com wrote:
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start
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
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
maybe $hashref = decode_hstore_literal('x=1, y=2').
I don't
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 $_TD = shift;
Pre-extend stack for trigger
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
[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:
Andrew Dunstan
On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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'T
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 between SvTYPE(sv
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
environment, no?
We
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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.25 (which has assorted fixes
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
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 will
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 end up
caching a lot of extra stuff that would
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's 2.22. 2.21 is already dead.
Oops, typo
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. That's
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 called with.
Why?
It keeps the code simple
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 plperl.use_strict
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
paramTypes Oid values of 0.
Yes
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. For example:
'pi()'
'generate_series
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
to try to wrap things up.
* Package namespace and Safe
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 great.
Thanks!
PostgreSQL::PLPerl::Call - Simple
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 in the next week or so.
I'd greatly appreciate
(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 tim.bu...@pobox.com
Date: Mon Feb 15 11:18:07 2010 +
Move on_proc_exit
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 = get_call('nextval(regclass)');
$foo1 = $seq_fn-($seq1
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)
test script.
I plan to release
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.
I could allow call('foo', @args), which could
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 switching
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
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 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 /Users/timbo/pg
On Fri, Feb 12, 2010 at 02:30:37PM -0700, Alex Hunsaker wrote:
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan and...@dunslane.net 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
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 plperl.on_plperl_init and plperl.on_plperlu_init GUCs
Both
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.
I'll add
[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
version
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
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
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.
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 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
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 Mon, Feb 01, 2010 at 07:53:05PM -0700, Alex Hunsaker wrote:
On Mon, Feb 1, 2010 at 03:58, Tim Bunce tim.bu...@pobox.com 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 slip-up when I merged
On Sat, Jan 30, 2010 at 06:38:59PM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 16:16, Tim Bunce tim.bu...@pobox.com 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 $PostgreSQL$ keyword
On Mon, Feb 01, 2010 at 10:46:10AM -0500, Robert Haas wrote:
On Mon, Feb 1, 2010 at 5:58 AM, Tim Bunce tim.bu...@pobox.com 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 worked
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 with Tom Lane and others.
Changes in this patch
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 a
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 Sat, Jan 30, 2010 at 11:08:26AM -0700, Alex Hunsaker wrote:
On Sat, Jan 30, 2010 at 07:51, Tim Bunce tim.bu...@pobox.com 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
nitpicking... It looks
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
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 discussions with Tom Lane and others.
Changes in this patch
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.8.x and the notnull attributes
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 Wed, Jan 27, 2010 at 06:33:19PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 of the backend --- there's actually
On Wed, Jan 27, 2010 at 06:27:50PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 could use use
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 =
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
On Thu, Jan 28, 2010 at 10:39:33AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 from using SPI
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 +, Tim Bunce wrote:
This is the fourth of the patches to be split out from the former
'plperl feature patch 1'.
Changes in this patch:
I think
On Thu, Jan 28, 2010 at 12:49:20PM -0500, Tom Lane wrote:
Joe Conway m...@joeconway.com 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
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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 Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 are not available when the code is run
On Wed, Jan 27, 2010 at 01:14:16AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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 normal interpreter destruction behaviour
END
On Wed, Jan 27, 2010 at 11:13:43AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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, during the shutdown sequence
On Wed, Jan 27, 2010 at 12:08:48PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 the sort of random user
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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't involve plperl at all. (Alternatively I
On Sat, Jan 23, 2010 at 06:40:03PM -0700, Alex Hunsaker wrote:
On Sat, Jan 23, 2010 at 16:16, Tim Bunce tim.bu...@pobox.com wrote:
On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
On Thu, Jan 14, 2010 at 09:07, Tim Bunce tim.bu...@pobox.com wrote:
I'd vote for use warnings
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
anyway to make a patch that applies cleanly.
I want to deal
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
- Restructured Safe compartment setup
On Fri, Jan 22, 2010 at 08:59:10PM -0700, Alex Hunsaker wrote:
On Thu, Jan 14, 2010 at 09:07, Tim Bunce tim.bu...@pobox.com wrote:
- 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.
[ BTW I
On Thu, Jan 21, 2010 at 07:55:09PM -0500, Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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
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
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::Cover _much_ more useful
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,
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
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.
On Tue, Jan 12, 2010 at 07:06:59PM -0500, Robert Haas wrote:
On Sun, Jan 10, 2010 at 4:35 PM, Robert Haas robertmh...@gmail.com 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
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.
-
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
On Sun, Jan 10, 2010 at 01:16:13AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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'd be left
with a broken
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 above.
- Optimized pg_verifymbstr calls to avoid
On Fri, Jan 08, 2010 at 10:36:43PM -0500, Robert Haas wrote:
On Fri, Jan 8, 2010 at 10:01 AM, Tim Bunce tim.bu...@pobox.com 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 earlier
plperl refactoring
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 appearing as
On Sat, Jan 09, 2010 at 11:16:18PM +0200, Peter Eisentraut wrote:
On fre, 2010-01-08 at 12:46 +, Tim Bunce wrote:
*** 45,50
--- 45,55
include $(top_srcdir)/src/Makefile.shlib
+ plperl.o: perlchunks.h
+
+ perlchunks.h: plc_*.pl
+ $(PERL) text2macro.pl
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 +, Tim Bunce wrote:
*** 45,50
--- 45,55
include $(top_srcdir)/src/Makefile.shlib
+ plperl.o
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 the
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 well. Anyone
On Wed, Jan 06, 2010 at 08:46:11PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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 configure reject
Perl
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
On Thu, Jan 07, 2010 at 05:45:08PM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
Is there any reason not to add .gitignore files into the repository?
I already find the .cvsignore files to be useless and an annoyance
On Tue, Jan 05, 2010 at 06:54:36PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
Definite benefit, there. How does it handle the difference between
IMMUTABLE | STABLE | VOLATILE, as well as STRICT functions
On Tue, Jan 05, 2010 at 07:06:35PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
The only question I have at the moment, before I try implementing this,
is the the need for freeing the plan. When would that be needed?
There's probably no strong need to do it at all,
That's
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 safe
On Wed, Jan 06, 2010 at 11:41:46AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
1 - 100 of 127 matches
Mail list logo