---------- Forwarded message ---------- From: Oleg Serov<serovov@gmail.com> Date: 2008/9/27 Subject: Re: Null row vs. row of nulls in plpgsql To: Tom Lane <tgl@sss.pgh.pa.us>
I'm newbie, but i think that adding bool flag to PLpgSQL_row isnull will handle the problem(like in PLpgSQL_var);
ISTM that the fundamental problem is that plpgsql doesn't distinguish properly between a null row value (eg, "null::somerowtype") and a row of null values (eg, "row(null,null,...)::somerowtype"). When that code was designed, our main SQL engine was pretty fuzzy about the difference too, but now there is a clear semantic distinction.
For plpgsql's RECORD variables this doesn't seem hard to fix: just take out the code in exec_move_row() that manufactures a row of nulls when the input is null, and maybe make a few small adjustments elsewhere. For ROW variables there's a bigger problem, because those are represented by a list of per-field variables, which doesn't immediately offer any way to represent overall nullness. I think it could be dealt with by adding an explicit "the row as a whole is null" flag to struct PLpgSQL_row. I haven't tried to code it though, so I'm not sure if there are gotchas or unreasonably large code changes needed to make it happen.
I thought for a little bit about whether we couldn't get rid of ROW variables entirely, or at least make them work more like RECORD variables by storing a HeapTuple instead of a list of per-field variables. But I soon found out that the reason to have them is to be able to describe the assignment target of SQL statements that assign to multiple scalar variables, eg "SELECT ... INTO x,y,z".
