Re: Bug with FOR ... LOOP and composite types - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Bug with FOR ... LOOP and composite types
Date
Msg-id 21527.1220285106@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug with FOR ... LOOP and composite types  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-bugs
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> 2008/9/1 Oleg Serov <serovov@gmail.com>:
>> Seems there is an error when I try to use a table with one field - composite
>> type, when SELECT QUERY in FOR ... LOOP instruction returns empty result.

> ROWTYPE is problem.

I think it actually is a bug.  exec_for_query tries to set the target to
null this way:

        exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);

and exec_move_row thinks it doesn't have to present a valid "valtype"
to exec_assign_value when it's assigning a made-up null, and that fails
when the target is of PLPGSQL_DTYPE_ROW type (looks like it'd fail for
REC type too, but ROW is the case here).

We could work around the particular issue by moving the
type_is_rowtype() tests down so they're not done for a null source
value, but I think that's just a hack.  A cleaner fix would be to teach
exec_move_row to present the correct column type in all cases.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "could not reattach to shared memory"
Date:
Subject: BUG #4389: FATAL: could not reattach to shared memory (key=1804, addr=018E0000): 487
Next
From: Tom Lane
Date:
Subject: Re: Bug in RETURN QUERY