I also suppose, that the new implementation is more consistent, but probably
a hint in the compatibility list should be done, so that after migration
Stored Procedures that are using the buggy implementation on the 8.4 should
be rewritten.
And the rewriting should be done either only after the migration, or in 8.4
to use the
rec.var := ( SELECT ROW(..) .. );
syntax.
With my best regards,
-- Valentine Gogichashvili
On Wed, Sep 8, 2010 at 5:42 PM, 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
> > 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
>
