Valentine Gogichashvili <val...@gmail.com> writes:
> CREATE TYPE ta AS (a1 integer, a2 text);
> CREATE TYPE tb AS (b1 integer, b2 ta);
> DECLARE
> a ta;
> b tb;
> BEGIN
> SELECT 1, 'a' INTO a; -- ok
> SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
> invalid input syntax for integer: "(10,a)"]
> SELECT 100, 'a' INTO b.b2; -- ok in 9.0 but fails in 8.4 [ERROR: cannot
> assign non-composite value to a row variable]
[ pokes around for a bit ... ] This is a consequence of the plpgsql
lexer rewrite I did for 9.0. In the previous code, "INTO b.b2" was
treated by the lexer as an assignment to a scalar variable, regardless
of the actual data type of b2. Which means that the SELECT has to
produce a single column that gets assigned to b.b2, so your first case
works and your second doesn't. The new code looks at the data type
of b2 rather than whether it's syntactically a field reference, so it
decides this is an assignment to a composite variable. That results in
behavior similar to the "INTO a" case: the SELECT is supposed to produce
one column for each field of the composite variable. Hence, second case
works and first doesn't.
I am not sure how ugly a kluge would be needed to restore the previous
behavior. I'm inclined to say that the new behavior is more
self-consistent and so we should call this a bug fix rather than a bug.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
