Re: BUG #5314: Error in nested composite types in plpgsql.

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