Re: BUG #5314: Error in nested composite types in plpgsql. - Mailing list pgsql-bugs

From Oleg Serov
Subject Re: BUG #5314: Error in nested composite types in plpgsql.
Date
Msg-id cec7c6df1002240412i3918354fo29f9cf15f4eebb72@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5314: Error in nested composite types in plpgsql.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5314: Error in nested composite types in plpgsql.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: RETURNS TABLE returns NULL set when called by another RETURNS TABLE
Next
From: Michael Meskes
Date:
Subject: Re: BUG #5327: postgresql gives checksum error when upgrading 8.2.6 binaries to 8.2.14 in windows.