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 <[EMAIL PROTECTED]> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
