On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Valentine Gogichashvili <valgog@gmail.com> writes:
>> CREATE TYPE ta AS (a1 integer, a2 text);
>> CREATE TYPE tb AS (b1 integer, b2 ta);
>
>> DECLARE
>> =A0a ta;
>> =A0b tb;
>> BEGIN
>
>> =A0SELECT 1, 'a' INTO a; =A0 =A0 =A0-- ok
>
>> =A0SELECT ROW(10, 'a') INTO b.b2; -- ok in 8.4 but fails in 9.0 [ERROR:
>> =A0invalid input syntax for integer: "(10,a)"]
>
>> =A0SELECT 100, 'a' INTO b.b2; =A0 -- ok in 9.0 but fails in 8.4 [ERROR: =
=A0cannot
>> assign non-composite value to a row variable]
>
> [ pokes around for a bit ... ] =A0This is a consequence of the plpgsql
> lexer rewrite I did for 9.0. =A0In 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. =A0Which 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. =A0The 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. =A0That results in
> behavior similar to the "INTO a" case: the SELECT is supposed to produce
> one column for each field of the composite variable. =A0Hence, second case
> works and first doesn't.
>
> I am not sure how ugly a kluge would be needed to restore the previous
> behavior. =A0I'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.
If we know the types of everything, is it possible to make both cases work?
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
