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
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
Tim Bunce tim.bu...@pobox.com 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?
Tim Bunce tim.bu...@pobox.com 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.
On Wed, Jan 6, 2010 at 9:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Tim Bunce tim.bu...@pobox.com 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
Robert Haas robertmh...@gmail.com 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
Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com 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
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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?
Andrew Dunstan and...@dunslane.net 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
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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 the results at all.
Whatever do you mean by take effect in the
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 the results at all.
Whatever do you mean
On Wed, Jan 06, 2010 at 11:14:38AM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
spi_rv = SPI_execute(query, current_call_data-prodesc-fn_readonly,
^^^
OK, but won't that automatically
Garick Hamlin gham...@isc.upenn.edu 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
Tom Lane wrote:
Garick Hamlin gham...@isc.upenn.edu 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
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 earlier
David E. Wheeler da...@kineticode.com 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
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
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
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 worth
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 versions less than $TBD. I thought we had agreed a week or so back
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
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
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 that
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
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
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?
It doesn't at the moment. I think IMMUTABLE, STABLE and
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, unless you are dropping
your last reference to the plan.
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 in
On Wed, Dec 30, 2009 at 7:41 PM, David E. Wheeler da...@kineticode.com 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
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 Wed, Dec 30, 2009 at 5:54 PM, Tim Bunce tim.bu...@pobox.com 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
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 guarantee
David E. Wheeler da...@kineticode.com 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
37 matches
Mail list logo
