Re: inconsistent composite type null handling in plpgsql out variable
От
Sam Mason
Тема
Re: inconsistent composite type null handling in plpgsql out variable
Дата
Msg-id
20090831172141.GG5407@samason.me.uk
Ответ на
Список
Дерево обсуждения
inconsistent composite type null handling in plpgsql out variable Merlin Moncure <mmoncure@gmail.com>
Re: inconsistent composite type null handling in plpgsql out variable Tom Lane <tgl@sss.pgh.pa.us>
Re: inconsistent composite type null handling in
plpgsql out variable "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: inconsistent composite type null handling in plpgsql out
variable Merlin Moncure <mmoncure@gmail.com>
Re: inconsistent composite type null handling in plpgsql out variable Sam Mason <sam@samason.me.uk>
Re: inconsistent composite type null handling in plpgsql out
variable Pavel Stehule <pavel.stehule@gmail.com>
Re: inconsistent composite type null handling in plpgsql out variable Sam Mason <sam@samason.me.uk>
Re: inconsistent composite type null handling in plpgsql out
variable Pavel Stehule <pavel.stehule@gmail.com>
On Fri, Aug 28, 2009 at 02:06:02PM -0400, Merlin Moncure wrote: > 3) If we decide the sql standard is correct, so that (null, null) is > null == true, then we should observe rule 1 and make things work in > consistent way. This means, for example, that null::foo and (null, > null)::foo should not be distinct. The more awkward case (to me anyway) is that the standard says (1,NULL) IS NULL should evaluate to TRUE. I'd never noticed the ROW / RECORD dichotomy before; could one of these be made SQL compatible and the other use more sane semantics? -- Sam http://samason.me.uk/
В списке pgsql-bugs по дате отправления
От: Heikki Linnakangas
Дата:
От: Pavel Stehule
Дата: