Re: revision of todo: NULL for ROW variables

From: Jim Nasby <jim(at)nasby(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: revision of todo: NULL for ROW variables
Date: 2010-11-01 14:44:35
Message-ID: FDECC2F9-2679-4B5F-9F6F-21F6BE3C9CB0@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Oct 28, 2010, at 11:41 AM, Merlin Moncure wrote:
> On Thu, Oct 28, 2010 at 10:15 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>> I am checking PLpgSQL ToDo topics, and I am not sure if this topic
>>> isn't done. And if not, then I would to get some detail.
>>
>> I think that thread petered out because we didn't have consensus on
>> what the behavior ought to be. It goes back to whether there is
>> supposed to be a difference between NULL and ROW(NULL,NULL,NULL,...)
>
> I think somewhere along the line it was noticed that SQL says you are
> supposed to treat (null, null) as null and the behavior of 'is null'
> operator was changed to reflect this while other null influenced
> behaviors were left intact (for example, coalesce()).
>
> My take on this is that we are stuck with the status quo. If a change
> must be done, the 'is null' change should be reverted to un-standard
> behavior. The SQL standard position on this issue is, IMNSHO, on
> mars.

As someone who's wanted this... what if we had a dedicated function to tell you if a row variable had been defined? I definitely don't like the though of creating something that effectively duplicates IS NULL, but I'd much rather that than continue not having the ability to tell if a row/record variable has been set or not.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-01 15:17:44 Re: Maximum function call nesting depth for regression tests
Previous Message Jim Nasby 2010-11-01 14:29:58 Re: Patch to add a primary key using an existing index