Re: Null row vs. row of nulls in plpgsql

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Oleg Serov <serovov(at)gmail(dot)com>
Subject: Re: Null row vs. row of nulls in plpgsql
Date: 2008-09-27 20:42:54
Message-ID: 1222548174.6993.23.camel@huvostro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2008-09-27 at 14:56 -0400, Tom Lane 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".

How hard would it be to have a RECORD that has pointers to those
multiple scalar variables ?

Referring again to my favorite ordinary programming language python, you
can have a very elegant way of assigning a "record" (a tuple in
pythonese) to a set of variables and vice versa

>>> rec = 1,2,3
>>> rec
(1, 2, 3)
>>> a,b,c = rec
>>> a
1
>>> c
3
>>> c,b,a
(3, 2, 1)

In other words, tuples are more or less automatically composed and
decomposed on demand.

I have not yet looked how hard the implementation of this would be for
postgreSQL, but at least the concept should be applicable.

----------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-27 21:00:49 Re: Null row vs. row of nulls in plpgsql
Previous Message Oleg Serov 2008-09-27 19:59:50 Fwd: Null row vs. row of nulls in plpgsql