Lists: | pgsql-bugs |
---|
From: | me(at)evancarroll(dot)com |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”? |
Date: | 2012-05-16 16:47:49 |
Message-ID: | E1SUhO9-00074q-53@wrigleys.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 6645
Logged by: Evna Carroll
Email address: me(at)evancarroll(dot)com
PostgreSQL version: 9.1.2
Operating system: Linux
Description:
This is a cross post from dba.stackexchange.com:
http://dba.stackexchange.com/q/17998/2639
The follow code used to work in Postgresql 8.4.11 with perl v5.10.1:
=# select * From testfunction();
testfunction
------------------------
http://www.google.com/
However, after doing a dump and load into Postgresql 9.1.3 with perl v5.14.2
I get:
ERROR: PL/Perl function must return reference to hash or array
CONTEXT: PL/Perl function "testfunction"
For reference, here is the function:
CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
use URI;
return URI->new('http://www.google.com/')->canonical;
$$ LANGUAGE plperlu;
Again, the version of perl changed from v5.10.1 to v5.14.2; however, the
return from Data::Peek is the same across both versions:
$ perl -MData::Peek -MURI -e'DPeek(
URI->new(q[http://www.google.com])->canonical
);'
Output on both versions of perl:
\PVMG("http://www.google.com/"\0)
From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | me(at)evancarroll(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”? |
Date: | 2012-05-16 17:27:34 |
Message-ID: | CAFaPBrTDd65PO7rrJZ8mZPffy-dQoJzvC0zc36QcOo3NfL7rnA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Wed, May 16, 2012 at 10:47 AM, <me(at)evancarroll(dot)com> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6645
> Logged by: Evna Carroll
> Email address: me(at)evancarroll(dot)com
> PostgreSQL version: 9.1.2
> Operating system: Linux
> Description:
>
> This is a cross post from dba.stackexchange.com:
> http://dba.stackexchange.com/q/17998/2639
>
> The follow code used to work in Postgresql 8.4.11 with perl v5.10.1:
> CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
> use URI;
> return URI->new('http://www.google.com/')->canonical;
> $$ LANGUAGE plperlu;
URI->canonical() returns some kind of blessed object, you can get it
to work by coercing the result to a string first:
CREATE OR REPLACE FUNCTION testfunction(OUT text) AS $$
use URI;
return URI->new('http://www.google.com/')->canonical().'';
$$ LANGUAGE plperlu;
We tightened this up over in:
commit 7c64c9f6b767b84597d69cfa2ae03d9a9655ec75
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Thu Oct 13 18:02:43 2011 -0400
Fix up Perl-to-Postgres datatype conversions in pl/perl.
This patch restores the pre-9.1 behavior that pl/perl functions returning
VOID ignore the result value of their last Perl statement. 9.1.0
unintentionally threw an error if the last statement returned a reference,
as reported by Amit Khandekar.
[...snip...]
In addition, ensure we throw errors for attempts to return arrays or hashes
when the function's declared result type is not an array or composite type,
respectively. Pre-9.1 versions rather uselessly returned strings like
ARRAY(0x221a9a0) or HASH(0x221aa90), while 9.1.0 threw an error for the
hash case and returned a garbage value for the array case.
[...snip...]
As noted above if you return a reference you would get a mostly
useless string like "HASH(0x...)". Post commit above it now gives you
the error "ERROR: cannot convert Perl hash to non-composite type
text" instead. That seemed better at the time because its almost
always a mistake (with what you return or your declared return type).
That being said it seems we failed to take any magic (aka string
overloads) that a blessed reference might have. Ill see about
submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
thoughts on if we should backpatch a fix?
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
Cc: | me(at)evancarroll(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”? |
Date: | 2012-05-16 17:53:11 |
Message-ID: | 29796.1337190791@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
Alex Hunsaker <badalex(at)gmail(dot)com> writes:
> That being said it seems we failed to take any magic (aka string
> overloads) that a blessed reference might have. Ill see about
> submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
> thoughts on if we should backpatch a fix?
Right offhand I'd be +1 for making that change, but not for backpatching
it; but I'm not a big plperl user. Would such a case have worked before
9.1? If it did and we broke it in 9.1, that would be a good reason to
back-patch into 9.1. If it never worked, then it sounds like a new
feature.
regards, tom lane
From: | Alex Hunsaker <badalex(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | me(at)evancarroll(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: [BUGS] Re: [BUGS] BUG #6645: Getting an error with “ERROR: PL/Perl function must return reference to hash or array”? |
Date: | 2012-05-16 18:22:04 |
Message-ID: | CAFaPBrSrTZquNwherCHUi7KspcA62hJuHp5iAbs7GgPRt5By_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Wed, May 16, 2012 at 11:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> That being said it seems we failed to take any magic (aka string
>> overloads) that a blessed reference might have. Ill see about
>> submitting a patch for 9.3 (9.2 just entered beta). Anyone have any
>> thoughts on if we should backpatch a fix?
>
> Right offhand I'd be +1 for making that change, but not for backpatching
> it; but I'm not a big plperl user. Would such a case have worked before
> 9.1? If it did and we broke it in 9.1, that would be a good reason to
> back-patch into 9.1. If it never worked, then it sounds like a new
> feature.
Yeah, it worked pre 9.1.