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
