Thread: BUG #5314: Error in nested composite types in plpgsql.
The following bug has been logged online: Bug reference: 5314 Logged by: Oleg Email address: serovov@gmail.com PostgreSQL version: 8.3/8.4 Operating system: any Description: Error in nested composite types in plpgsql. Details: Here is it reproduce code: It works only, when procedure is plpgsql, with sql works fine. ROLLBACK; BEGIN; CREATE TABLE bug_level_tree( field BIGINT ); CREATE TABLE bug_level_two( field bug_level_tree ); CREATE TABLE bug_level_one( id BIGINT, field bug_level_two ); CREATE FUNCTION bug_procedure(in_row bug_level_one) RETURNS text AS $$ BEGIN -- void SELECT 1/0; END; $$ LANGUAGE plpgsql; -- All okey SELECT '(1,)'::bug_level_one; -- Throws error SELECT bug_procedure('(1,)'); -- ERROR: cannot assign non-composite value to a row variable CONTEXT: PL/pgSQL function "bug_procedure" while storing call arguments into local variables
Somebody will fix this bug or not? On Thu, Feb 4, 2010 at 7:13 PM, Oleg <serovov@gmail.com> wrote: > > The following bug has been logged online: > > Bug reference: 5314 > Logged by: Oleg > Email address: serovov@gmail.com > PostgreSQL version: 8.3/8.4 > Operating system: any > Description: Error in nested composite types in plpgsql. > Details: > > Here is it reproduce code: > It works only, when procedure is plpgsql, with sql works fine. > > ROLLBACK; > BEGIN; > CREATE TABLE bug_level_tree( > field BIGINT > ); > CREATE TABLE bug_level_two( > field bug_level_tree > ); > CREATE TABLE bug_level_one( > id BIGINT, > field bug_level_two > ); > CREATE FUNCTION bug_procedure(in_row bug_level_one) RETURNS text AS $$ > BEGIN > -- void > SELECT 1/0; > END; > $$ LANGUAGE plpgsql; > > -- All okey > SELECT '(1,)'::bug_level_one; > > -- Throws error > SELECT bug_procedure('(1,)'); > > -- ERROR: cannot assign non-composite value to a row variable > CONTEXT: PL/pgSQL function "bug_procedure" while storing call arguments > into local variables > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > --=20 =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD =EF=CC=C5=C7 =F3=C5=D2=CF=D7
2010/2/10 Oleg Serov <serovov@gmail.com>: > Somebody will fix this bug or not? I'm not sure whether this is a bug. This is an explicit cast: SELECT '(1,)'::bug_level_one; But I think this is an implicit cast: SELECT bug_procedure('(1,)'); I'm not totally sure of the details, but implicit, assignment, and explicit casts are documented to have different semantics: http://www.postgresql.org/docs/current/static/sql-createcast.html ...Robert
Robert Haas <robertmhaas@gmail.com> writes: > 2010/2/10 Oleg Serov <serovov@gmail.com>: >> Somebody will fix this bug or not? > I'm not sure whether this is a bug. Yeah, I think it is. The problem is that exec_move_row is taking too many shortcuts with nulls. If the input record is short of fields it is willing to pass this data to exec_assign_value: value = (Datum) 0; isnull = true; valtype = InvalidOid; The invalid datatype value doesn't matter in the scalar case, but if the target is a sub-row it fails the type_is_rowtype() sanity check in exec_assign_value. The cleanest fix would probably be to use the target variable's datatype here instead of InvalidOid. Alternatively, we could change exec_assign_value to not apply the sanity check unless the input is non-null. regards, tom lane
When it could be fixed? On Thu, Feb 11, 2010 at 9:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> 2010/2/10 Oleg Serov <serovov@gmail.com>: >>> Somebody will fix this bug or not? > >> I'm not sure whether this is a bug. > > Yeah, I think it is. =9AThe problem is that exec_move_row is taking too > many shortcuts with nulls. =9AIf the input record is short of fields it > is willing to pass this data to exec_assign_value: > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avalue =3D = (Datum) 0; > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aisnull =3D= true; > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Avaltype = =3D InvalidOid; > > The invalid datatype value doesn't matter in the scalar case, but > if the target is a sub-row it fails the type_is_rowtype() sanity > check in exec_assign_value. > > The cleanest fix would probably be to use the target variable's > datatype here instead of InvalidOid. =9AAlternatively, we could > change exec_assign_value to not apply the sanity check unless > the input is non-null. > > =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9A =9Aregards, tom lane > --=20 =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD =EF=CC=C5=C7 =F3=C5=D2=CF=D7
Oleg Serov <serovov@gmail.com> writes: > When it could be fixed? Oh, it is fixed, but I forgot to reply to this thread about it. Sorry about that. regards, tom lane
Thanks!, when it will be released on 8.3.X? On Wed, Feb 24, 2010 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Oleg Serov <serovov@gmail.com> writes: > > When it could be fixed? > > Oh, it is fixed, but I forgot to reply to this thread about it. > Sorry about that. > > regards, tom lane > --=20 =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD =EF=CC=C5=C7 =F3=C5=D2=CF=D7
2010/2/25 Oleg Serov <serovov@gmail.com>: > Thanks!, when it will be released on 8.3.X? Looks like the last set of back-branch releases was wrapped 12/10/09, the set before that on 9/4/09, and the previous set on 3/13/09 (but there was a major release in the mix there). So I'd guess we're getting close to it being time for another set... ...Robert