Composite types are converted to and from Perl hashes since commit
REL9_1_ALPHA4~146 (Convert Postgres arrays to Perl arrays on PL/perl input
arguments; 2011-02-17), but are not stringified as claimed by the commit
message and release notes (unless nested in an array).
To illustrate:
CREATE TYPE foo AS (bar INTEGER, baz TEXT);
DO $$ my $val = spi_exec_query(q< SELECT ROW(42,'test')::foo AS col
>)->{rows}->[0]->{col}; elog(NOTICE, "$val ".ref($val)) $$ LANGUAGE plperl;
NOTICE: HASH(0xb864a744) HASH
DO $$ my $val = spi_exec_query(q< SELECT ARRAY[ ROW(42,'test')::foo ] AS col
>)->{rows}->[0]->{col}; elog(NOTICE, "$val ".ref($val)) $$ LANGUAGE plperl;
NOTICE: {"(42,test)"} PostgreSQL::InServer::ARRAY
On pg 9.0 the expected (but unblessed) strings (42,test) and {"(42,test)"}
are returned respectively.
To make matters worse, received values cannot be used in queries because
spi_exec_prepared() simply ignores hash arguments:
# DO $$ my $q = spi_prepare('SELECT $1 AS col', 'foo' ); elog(NOTICE,
spi_exec_prepared($q, { bar=>42, baz=>'test' } )->{rows}->[0]->{col}) $$
LANGUAGE plperl;
ERROR: spi_exec_prepared: expected 1 argument(s), 0 passed at line 1.
Again except if nested in an array:
# DO $$ my $q = spi_prepare('SELECT $1 AS col', 'foo[]'); elog(NOTICE,
spi_exec_prepared($q, [{ bar=>42, baz=>'test' }])->{rows}->[0]->{col}) $$
LANGUAGE plperl;
NOTICE: {"(42,test)"}
While the intended feature would be very welcome as well, not being able
to convert to text is a serious regression.
Thanks and regards,
--
Mischa
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
