of IS NULL for rows. As long as you maintain that level of spec-
compliance I don't think there are any other important constraints on
--sorry for the top posting but the phone makes it hard to do anything
On 27 Sep 2008, at 09:56 PM, Tom Lane <email@example.com> wrote:
> I looked a bit at the bug report here:
> 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
> 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
> 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
> the assignment target of SQL statements that assign to multiple scalar
> variables, eg "SELECT ... INTO x,y,z".
> regards, tom lane
> Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
> To make changes to your subscription: