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
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 |