On Feb 24, 2010, at 5:10 PM, Tom Lane wrote:
Richard Huxton writes:
On 24/02/10 21:34, Tom Lane wrote:
Hmm. Jeff found some relevant material on perlref. Should that
link be
added? Should the link(s) be more specific than telling you to
read the
whole d*mn man page? Neither of those p
Richard Huxton writes:
> On 24/02/10 21:34, Tom Lane wrote:
>> Hmm. Jeff found some relevant material on perlref. Should that link be
>> added? Should the link(s) be more specific than telling you to read the
>> whole d*mn man page? Neither of those pages are short, and each contains
>> a weal
On 24/02/10 21:34, Tom Lane wrote:
Richard Huxton writes:
On 24/02/10 20:55, Tom Lane wrote:
but if plperl is doing something that contributes to this, maybe it
requires documentation.
It is documented.
http://www.postgresql.org/docs/8.4/static/plperl-funcs.html
Hmm. Jeff found some
Richard Huxton writes:
> On 24/02/10 20:55, Tom Lane wrote:
>> but if plperl is doing something that contributes to this, maybe it
>> requires documentation.
> It is documented.
> http://www.postgresql.org/docs/8.4/static/plperl-funcs.html
> Note: The use of named nested subroutines is da
On 24/02/10 20:55, Tom Lane wrote:
Jeff writes:
[ oracular excerpt from perlref ]
So is this just a dark corner of Perl, or is plperl doing something to
help you get confused? In particular, do we need to add anything to
the plperl documentation? We're not trying to explain Perl to people,
Jeff writes:
> [ oracular excerpt from perlref ]
So is this just a dark corner of Perl, or is plperl doing something to
help you get confused? In particular, do we need to add anything to
the plperl documentation? We're not trying to explain Perl to people,
but if plperl is doing something that
On Feb 24, 2010, at 8:44 AM, Jeff wrote:
Notice on the second run the plan is still "beef" when it was set to
49abf0 (which when passed as the arg is correct)
Any perl gurus have any further info on this? It was a bit
surprising to encounter this. I'm guessing it has something to do
wit
Ran into this switching a DBI based thing into a plperl function. The
root cause is probably a perl variable scope thing, but still this is
very interesting behavior and may trip up others.
Given code such as this:
create or replace function plperlhell()
returns int
as $$
# prepare a plan,
