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 по дате отправления:

Предыдущее
От: "Daniel Verite"
Дата:
Сообщение: Re: comparing NEW and OLD (any good this way?)
Следующее
От: Kelly Burkhart
Дата:
Сообщение: synchronous_commit and mvcc