Re: revision of todo: NULL for ROW variables
От | Jim Nasby |
---|---|
Тема | Re: revision of todo: NULL for ROW variables |
Дата | |
Msg-id | FDECC2F9-2679-4B5F-9F6F-21F6BE3C9CB0@nasby.net обсуждение исходный текст |
Ответ на | Re: revision of todo: NULL for ROW variables (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: revision of todo: NULL for ROW variables
|
Список | 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@sss.pgh.pa.us> wrote: >> Pavel Stehule <pavel.stehule@gmail.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 definitelydon't like the though of creating something that effectively duplicates IS NULL, but I'd much rather that thancontinue not having the ability to tell if a row/record variable has been set or not. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: