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 configure reject
> >>> Perl versions l
On Jan 6, 2010, at 5:46 PM, Tom Lane wrote:
> I went with 5.8 as the cutoff, for a couple of reasons: we're not in
> the business of telling people they ought to be up-to-date, but only of
> rejecting versions that demonstrably fail badly; and I found out that
> older versions of awk are not suffi
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 configure reject
>>> Perl versions less than $TBD. I thought we had agreed a week or so back
>>> that 5
On Jan 6, 2010, at 3:31 PM, Tim Bunce wrote:
> For 8.5 I don't think I'll even attempt direct inter-plperl-calls.
>
> I'll just do a nicely-sugared wrapper around spi_exec_prepared().
> Either via import, as I outlined earlier, or Garick Hamlin's suggestion
> of attributes - which is certainly wo
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
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 version because of utf8 and other
> considerations.
+1, and 5.8.3 at a
"David E. Wheeler" writes:
> Which likely also means 5.6.1 and quite possibly 5.6.0. I don't recommend
> anything earlier than 5.6.2, though, frankly, and 5.8.9 is a better choice.
> 5.10.1 better still. Is there a documented required minimum version for
> PL/Perl?
One of the things on my to-d
On Jan 6, 2010, at 11:27 AM, Andrew Dunstan wrote:
> That's a case of out of date docco more than anything else, AFAIK. It's been
> there at least since 5.6.2 (which is the earliest source I have on hand).
Which likely also means 5.6.1 and quite possibly 5.6.0. I don't recommend
anything earlie
Tom Lane wrote:
Garick Hamlin writes:
If you want 'a perl compile time hook', those are called attributes.
http://search.cpan.org/~dapm/perl-5.10.1/lib/attributes.pm
Hm ... first question that comes to mind is how far back does that work?
The comments on that page about this or that
Garick Hamlin writes:
> If you want 'a perl compile time hook', those are called attributes.
> http://search.cpan.org/~dapm/perl-5.10.1/lib/attributes.pm
Hm ... first question that comes to mind is how far back does that work?
The comments on that page about this or that part of it being still
ex
On Wed, Jan 06, 2010 at 11:14:38AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
> >> ^^^
>
> > OK, but won't that automatically supply t
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 all.
>
> Whatever do you mean by "take ef
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 all.
Whatever do you mean by "take effect in the caller's context
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
^^^
OK, but won't that automatically supply the value from the function
called from
Andrew Dunstan writes:
> Tom Lane wrote:
>> spi_rv = SPI_execute(query, current_call_data->prodesc->fn_readonly,
>> ^^^
> OK, but won't that automatically supply the value from the function
> called from postgres, which will be the
Tom Lane wrote:
Andrew Dunstan writes:
I don't understand that phrase "call SPI with the right arguments for
the type of function you're currently in". What calls that we make from
plperl code would have different arguments depending on the volatility
of the function?
eg, in plper
Andrew Dunstan writes:
> I don't understand that phrase "call SPI with the right arguments for
> the type of function you're currently in". What calls that we make from
> plperl code would have different arguments depending on the volatility
> of the function?
eg, in plperl_spi_exec,
Tom Lane wrote:
Tim Bunce writes:
For my own benefit, being a PostgreSQL novice, could you expand a little?
For example, given two stored procedures, A and V, where V is marked
VOLATILE and both are plperl. How would having A call V directly, within
the plperl interpreter, cause problems?
Robert Haas writes:
> I think what we should do is either (1) implement a poor man's caching
> that doesn't try to cope with any of these issues, and document that
> you get what you pay for or (2) reject this idea in its entirety.
> Trying to reimplement all of our normal function call semantics
On Wed, Jan 6, 2010 at 9:46 AM, Tom Lane wrote:
> Tim Bunce writes:
>> For my own benefit, being a PostgreSQL novice, could you expand a little?
>> For example, given two stored procedures, A and V, where V is marked
>> VOLATILE and both are plperl. How would having A call V directly, within
>> t
Tim Bunce writes:
> Let me ask the question another way... is there any reason to drop plans
> other than limiting memory usage?
No, that's about it. The only reason to care is if you'd otherwise have
a code path that would repetitively leak plans.
regards, tom lane
--
Tim Bunce writes:
> For my own benefit, being a PostgreSQL novice, could you expand a little?
> For example, given two stored procedures, A and V, where V is marked
> VOLATILE and both are plperl. How would having A call V directly, within
> the plperl interpreter, cause problems?
That case is fi
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 do it at all,
That's good.
> unle
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 STRICT functions?
>
> > It doe
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 do it at all, unless you are dropping
your last reference to the plan.
regards
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 STRICT functions?
> It doesn't at the moment. I think IMMUTABLE, STABLE and VOLATILE can be
> (d
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.
> > Sounds like you're more keen
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 on syntactic sugar.
I'm saying do both. Make the cached version the one th
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
> >$c
On Wed, Dec 30, 2009 at 7:41 PM, David E. Wheeler wrote:
> On Dec 30, 2009, at 4:17 PM, Robert Haas 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{$n
On Dec 30, 2009, at 2:54 PM, Tim Bunce wrote:
> That handles the arity of the calls and invokes the right SP, bypassing
> SQL if the SP is already loaded.
Nice.
> That much works currently. Behind the scenes, when a stored procedure is
> loaded into plperl the code ref for the perl sub is stored
"David E. Wheeler" writes:
> On Dec 30, 2009, at 4:17 PM, Robert Haas wrote:
>> That doesn't seem like enough to guarantee that you've got the right
>> function.
> As Tim said elsewhere:
>> I don't see either of those as significant issues: "If you need more
>> control for a particular SP then do
On Dec 30, 2009, at 4:17 PM, Robert Haas 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{$name}[$nargs] = $coderef;
>
> That doesn't seem like enough to gu
On Wed, Dec 30, 2009 at 5: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{$name}[$nargs] = $coderef;
That doesn't seem like enough to guarante
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
37 matches
Mail list logo
