Re: Bug with FOR ... LOOP and composite types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "Oleg Serov" <serovov(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bug with FOR ... LOOP and composite types
Date: 2008-09-01 16:05:06
Message-ID: 21527.1220285106@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2008/9/1 Oleg Serov <serovov(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-09-01 16:22:50 Re: Bug in RETURN QUERY
Previous Message could not reattach to shared memory 2008-09-01 15:09:23 BUG #4389: FATAL: could not reattach to shared memory (key=1804, addr=018E0000): 487