On Thu, Nov 19, 2009 at 05:04:22PM -0700, Joshua Tolley wrote:
The body of the function is ordinary Perl code. In fact, the PL/Perl
!glue code wraps it inside a Perl subroutine. Anonymous code blocks cannot
!return a value; PL/Perl functions created with CREATE FUNCTION must
I've started work on the enhancements to plperl I outlined on pg-general
(XXX thread)
I have a working implementation of those changes, plus some performance
enhancements, that I'm now re-working into a clean set of tested and
polished patches.
This patch is a first step that doesn't add any
On Tue, Nov 24, 2009 at 11:57:06AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
The next step I plan is to move the large multi-line string literal
macros (PERLBOOT, SAFE_OK etc) into external perl code files.
That'll make refactoring, extending and maintaining that perl
Following on from my earlier draft plperl.c refactoring patch, here's a
new version that's complete (from my perspective at least).
I've started work on the enhancements to plperl I outlined on pg-general
(in the Wishlist of PL/Perl Enhancements for 8.5 thread).
I have a working implementation of
On Sat, Nov 28, 2009 at 09:35:10AM -0500, Andrew Dunstan wrote:
Tim Bunce wrote:
- Changed MULTIPLICITY check from runtime to compiletime.
No loads the large Config module.
ISTM the trouble with this is that it assumes that the library that we
compile with is the same as the library
On Mon, Nov 30, 2009 at 12:50:41PM -0500, Andrew Dunstan wrote:
Tim Bunce wrote:
In summary, changing between multiplicity and non-multiplicity libperls
after building postgresql isn't safe or supported.
OK, good. Are you adding a check at load time that the library loaded is
what we
I've attached an update of my previous refactoring of plperl.c.
It's been rebased over the current (git) HEAD and has a few
very minor additions.
Background:
I've started work on the enhancements to plperl I outlined on pg-general
(in the Wishlist of PL/Perl Enhancements for 8.5 thread).
I have
Building on my earlier plperl refactoring patch, here's a draft of my
first plperl feature patch.
Significant changes in this patch:
- New GUC plperl.on_perl_init='...perl...' for admin use.
- New GUC plperl.on_trusted_init='...perl...' for plperl user use.
- New GUC
On Thu, Dec 03, 2009 at 04:53:47PM -0800, David E. Wheeler wrote:
On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
- New GUC plperl.on_perl_init='...perl...' for admin use.
- New GUC plperl.on_trusted_init='...perl...' for plperl user use.
- New GUC plperl.on_untrusted_init='...perl
On Fri, Dec 04, 2009 at 11:01:42AM -0500, Tom Lane wrote:
Jeff thres...@threshar.is-a-geek.com writes:
Is there any possible way to enable use strict; for plperl (trusted)
modules?
The plperl manual shows a way to do it using some weird syntax or
other. It'd sure be nice to be able to
On Thu, Dec 03, 2009 at 03:47:21PM -0800, Josh Berkus wrote:
Tim,
Since there's a commitfest on right now, meaningful feedback on your
patch could be delayed. Just so you know.
Understood. Thanks Josh.
Tim.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Fri, Dec 04, 2009 at 02:05:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
So, do we look for another way to provide the functionality besides
having a GUC, or is the functionality itself bad?
I don't think we want random Perl code running inside the postmaster,
On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Tom, what's your objection to Shlib load time being user-visible?
It's not really designed to be user-visible. Let me give you just
two examples:
* We call a plperl function for the
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
I'll modify the patch to disable the SPI functions during
initialization (both on_perl_init and on_(un)trusted_init).
Yeah, in the shower this morning I was thinking that not loading
SPI till
On Mon, Dec 07, 2009 at 07:07:13PM -0500, Andrew Dunstan wrote:
Josh Berkus wrote:
Not everything is sanely convertible into some sort of plugin. A plugin
mechanism for this would be FAR more trouble that it is worth, IMNSHO.
We are massively over-egging this pudding (as a culinary blogger
On Sun, Dec 20, 2009 at 10:55:55PM -0500, Robert Haas wrote:
On Sun, Dec 20, 2009 at 10:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
On Monday 21 December 2009 02:23:39 Robert Haas wrote:
A more important point is whether we really need to make this
I've submitted this patch to the open CommitFest
https://commitfest.postgresql.org/action/patch_view?id=245
Tim.
On Wed, Nov 25, 2009 at 03:36:25PM +, Tim Bunce wrote:
Following on from my earlier draft plperl.c refactoring patch, here's a
new version that's complete (from my perspective
On Mon, Dec 21, 2009 at 10:09:58AM -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
2009/12/21 Robert Haas robertmh...@gmail.com:
On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce tim.bu...@pobox.com wrote:
plperl requires Safe v2.09, released in Oct 2003 and included in 5.8.1
On Mon, Dec 21, 2009 at 08:22:54AM -0800, David E. Wheeler wrote:
On Dec 21, 2009, at 7:18 AM, Tim Bunce wrote:
Given the above three things it seems like we could define 5.8.1 as the
minimum required version.
I'd be delighted with that.
+1
BTW Tim, have you tested with 5.11 yet
On Mon, Dec 21, 2009 at 02:46:17PM -0500, Andrew Dunstan wrote:
David E. Wheeler wrote:
At least I think it's a segfault. This function returns a vstring:
CREATE OR REPLACE FUNCTION wtf(
) RETURNS text LANGUAGE plperl IMMUTABLE STRICT AS $X$
return $^V;
$X$;
Here's what happens when
On Fri, Dec 25, 2009 at 12:54:13PM -0500, Andrew Dunstan wrote:
Tim Bunce wrote:
I've attached an update of my previous refactoring of plperl.c.
It's been rebased over the current (git) HEAD and has a few
very minor additions.
[snip]
+ -- Test compilation of unicode regex
+ --
+ CREATE
On Thu, Dec 24, 2009 at 11:08:49AM -0500, Andrew Dunstan wrote:
Tim Bunce wrote:
I'm about ready to post the next draft of my plperl feature patch.
When I looked at the diff I saw ~7800 lines of it were just due to
updating ppport.h. So I've broken that out into this large but totally
While waiting for feedback on my earlier plperl refactor and feature
patches I'm working on a further patch that adds, among other things,
fast inter-plperl-sp calling.
I want to outline what I've got and get some feedback on open issues.
To make a call to a stored procedure from plperl you just
On Thu, Dec 31, 2009 at 09:47:24AM -0800, David E. Wheeler wrote:
On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
That much works currently. Behind the scenes, when a stored procedure is
loaded into plperl the code ref for the perl sub is stored in a cache.
Effectively just
$cache
On Tue, Jan 05, 2010 at 01:05:40PM -0800, David E. Wheeler wrote:
On Jan 5, 2010, at 12:59 PM, Tim Bunce wrote:
So you're suggesting SP::foo(...) _always_ executes foo(...) via bunch
of spi_* calls. Umm. I thought performance was a major driving factor.
Sounds like you're more keen
Ok, Plan B...
Consider this (hypothetical) example:
CREATE OR REPLACE FUNCTION test() ... LANGUAGE plperl AS $$
use SP foo_int = 'foo(int)';
use SP foo_text = 'foo(text)', -cached;
foo_int(42);
foo_text(42);
...
$$
Here the user is importing
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
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)
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 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 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 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
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 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.
-
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.
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
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
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 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 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 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 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 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 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 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 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
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 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 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 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 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 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
1 - 100 of 127 matches
Mail list logo
