Re: BUG #5644: Selecting ROW() in variable with 9.0 not compatible with 8.4

On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Valentine Gogichashvili <valgog(at)gmail(dot)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.

If we know the types of everything, is it possible to make both cases work?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company