On Tue, Jan 05, 2010 at 07:06:35PM -0500, Tom Lane wrote:
> Tim Bunce 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
On Tue, Jan 05, 2010 at 06:54:36PM -0500, Tom Lane wrote:
> Tim Bunce 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
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 i
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.
>
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.
&g
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 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'v
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]
&
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
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
On Mon, Dec 21, 2009 at 10:09:58AM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > 2009/12/21 Robert Haas :
> >> On Mon, Dec 21, 2009 at 5:45 AM, Tim Bunce wrote:
> >>> plperl requires Safe v2.09, released in Oct 2003 and included in 5.8.1.
> >>> T
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 +0000, Tim Bunce wrote:
> Following on from my earlier draft plperl.c refactoring patch, here's a
> new version that's complete
On Sun, Dec 20, 2009 at 10:55:55PM -0500, Robert Haas wrote:
> On Sun, Dec 20, 2009 at 10:23 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> On Monday 21 December 2009 02:23:39 Robert Haas wrote:
> >>> A more important point is whether we really need to make this
> >>> dependent on Perl 5.6 or
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 cul
On Sat, Dec 05, 2009 at 11:41:36AM -0500, Tom Lane wrote:
> Tim Bunce 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 lo
On Sat, Dec 05, 2009 at 01:21:22AM -0500, Tom Lane wrote:
> "David E. Wheeler" 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 first time i
On Fri, Dec 04, 2009 at 02:05:28PM -0500, Tom Lane wrote:
> Robert Haas 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,
> no matter what
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 11:01:42AM -0500, Tom Lane wrote:
> Jeff 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 use the regular syntax
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.
> >
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 plperl.on_untrusted_init='...
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
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
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
> comp
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 o
On Tue, Nov 24, 2009 at 11:57:06AM -0500, Tom Lane wrote:
> Tim Bunce 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 maintain
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 extra
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
> a
101 - 128 of 128 matches
Mail list logo
