Re: Null row vs. row of nulls in plpgsql

Iirc the reason for this fuzziness came from the SQL spec definition
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
pg behaviour.

greg

--sorry for the top posting but the phone makes it hard to do anything
else.

On 27 Sep 2008, at 09:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I looked a bit at the bug report here:
> http://archives.postgresql.org/pgsql-bugs/2008-09/msg00164.php
>
> 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".
>
> Comments?
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers