2009/9/1 Sam Mason :
> On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
>> 2009/8/31 Sam Mason :
>> > The more awkward case (to me anyway) is that the standard says (1,NULL)
>> > IS NULL should evaluate to TRUE.
>>
>> what?
>>
>> only (NULL, NULL) IS NULL is true
>
> Bah, sorry you're
On Mon, Aug 31, 2009 at 07:26:59PM +0200, Pavel Stehule wrote:
> 2009/8/31 Sam Mason :
> > The more awkward case (to me anyway) is that the standard says (1,NULL)
> > IS NULL should evaluate to TRUE.
>
> what?
>
> only (NULL, NULL) IS NULL is true
Bah, sorry you're right! I was rattling my favo
2009/8/31 Sam Mason :
> 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 (nul
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
On Fri, Aug 28, 2009 at 1:38 PM, Kevin
Grittner wrote:
> Merlin Moncure wrote:
>
>> This leads to some very weird behaviors, for example 'coalesce(foo,
>> something)' and 'case when foo is null then something else foo end'
>> can give different answers.
>
> Quite apart from the issue you're pursui
Merlin Moncure wrote:
> This leads to some very weird behaviors, for example 'coalesce(foo,
> something)' and 'case when foo is null then something else foo end'
> can give different answers.
Quite apart from the issue you're pursuing, this is another example of
how the COALESCE predicate in P
Merlin Moncure writes:
> Today I ran into a problem relating to $subject. plpgsql's handling
> of 'null' composite types is not consistent with what you get in sql:
Hm. It looks like plpgsql treats composite arguments as being "row"
instead of "record" variables, which has some possible efficie
Today I ran into a problem relating to $subject. plpgsql's handling
of 'null' composite types is not consistent with what you get in sql:
create table foo(a text, b text);
create table bar(id int, f foo);
insert into bar values (1, ('a', 'b'));
create or replace function f(_foo out foo) returns
