Richard Poole wrote:
Indeed. It would be Perlish to have some magic so that when you called
one PL/Perl function from another you could return an array ref from
the inner one and have it Do What You Mean in the outer one, too.
There is no way to have one plperl function call another directly
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote:
>> I would add these test cases to the regression test were it not that the
>> addresses are machine-dependent...
> I haven't looked into how the regression tests work -- can test
> output be post-
On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote:
>
> > CREATE FUNCTION test1() RETURNS TEXT AS $$
> > return ["test"];
> > $$ LANGUAGE plperl;
>
> > SELECT test1();
> > test1
> > --
> > ARRAY(0x8427a58)
> > (1 row)
>
> This is exactly what Perl will do if y
On Tue, Nov 23, 2004 at 11:37:22AM -0500, Tom Lane wrote:
> $ perl -e 'print ["test 1"], "\n"'
> ARRAY(0xa03ec28)
> $
>
> so I don't think a Perl programmer would find it surprising; if anything
> he'd probably complain if we *didn't* do that.
Understood, which is why I mentioned that such cases
Michael Fuhr <[EMAIL PROTECTED]> writes:
> How far do you want to go with checking return types? Some of the
> following test cases are approaching "garbage in, garbage out"
> territory and I don't know how much effort you want to put into
> protecting programmers from themselves. Some of the cas
On Mon, Nov 22, 2004 at 03:34:17PM -0500, Tom Lane wrote:
>
> Thanks for the examples. I extended this into a simple regression test
> which I've added to CVS. If anyone would like to add some test cases
> for more interesting stuff (triggers and error handling come to mind),
> step right up ...
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Here's another test case: a function that doesn't return what it's
> supposed to return.
Fixed, thanks.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe c
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Here's another test case: a function that doesn't return what it's
> supposed to return.
I was wondering about that --- the code paths that expect an array
seemed to be testing the SV type more carefully than those expecting
a hash did. Sigh.
On Mon, Nov 22, 2004 at 03:34:17PM -0500, Tom Lane wrote:
>
> Thanks for the examples. I extended this into a simple regression test
> which I've added to CVS. If anyone would like to add some test cases
> for more interesting stuff (triggers and error handling come to mind),
> step right up ...
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I discovered a further plperl bug last night. If foo() is a SRF and
> therefore returns an arrayref, calling select foo() rather than select *
> from foo() causes a segfault because this line passes NULL as the argument:
> tupdesc = CreateTupleDes
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I ran the following tests on 8.0.0beta5, which I think includes
> Tom's latest changes:
Thanks for the examples. I extended this into a simple regression test
which I've added to CVS. If anyone would like to add some test cases
for more interesting stuf
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I discovered a further plperl bug last night. If foo() is a SRF and
> therefore returns an arrayref, calling select foo() rather than select *
> from foo() causes a segfault because this line passes NULL as the argument:
> tupdesc = CreateTupleDes
On Mon, Nov 22, 2004 at 06:37:46AM -0600, Andrew Dunstan wrote:
>
> I discovered a further plperl bug last night. If foo() is a SRF and
> therefore returns an arrayref, calling select foo() rather than select *
> from foo() causes a segfault because this line passes NULL as the argument:
>
>
I discovered a further plperl bug last night. If foo() is a SRF and
therefore returns an arrayref, calling select foo() rather than select *
from foo() causes a segfault because this line passes NULL as the argument:
tupdesc = CreateTupleDescCopy(rsinfo->expectedDesc);
I am not sure I even k
14 matches
Mail list logo
