Re: comparing NEW and OLD (any good this way?)
От | Sam Mason |
---|---|
Тема | Re: comparing NEW and OLD (any good this way?) |
Дата | |
Msg-id | 20090812184534.GZ5407@samason.me.uk обсуждение исходный текст |
Ответ на | Re: comparing NEW and OLD (any good this way?) ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: comparing NEW and OLD (any good this way?)
|
Список | pgsql-general |
On Wed, Aug 12, 2009 at 08:02:10PM +0200, Daniel Verite wrote: >Sam Mason wrote: > > But it seems to be a somewhat arbitrary choice to handle > > IS NULL for rows differently from everything else. > > For scalar or array types, "is null" means that the value happens to be that > special value that we call null. No conceptual problem here. > But for rows, there is no such thing. You can't assign null to a row, it > makes no sense and actually causes an error. What makes you say this? There's no reason I can see that would cause row values should be special in this way. Maybe if you could define what you mean by "you can't assign null to a row"? > Starting from that point, what consistency can we expect for the "is null" > operator across row types and other types? Values of row type are the only time when v IS NOT NULL and NOT v IS NULL are not synonymous. > > Yes, I understand what it's specified to do and that it's consistent > > with SQL spec. I just think (and Merlin seems to agree) that the spec > > has specified the "wrong" behavior. > > So for you guys, what would be the "right" behavior? For me anyway, that the above actually holds true. -- Sam http://samason.me.uk/
В списке pgsql-general по дате отправления: