On Wed, Sep 8, 2010 at 11:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
