Re: BUG #6079: Wrong select result - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: BUG #6079: Wrong select result
Date
Msg-id BANLkTikwdP9utpjNTb9p7SmBJf57KPFMtA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #6079: Wrong select result  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: BUG #6079: Wrong select result
List pgsql-bugs
> 2011/6/28 Renat <renat.nasyrov@itv.ru>:
>>
>> create table foo (
>> id bigint not null,
>> date_to timestamp without time zone,
>> CONSTRAINT foo_pkey PRIMARY KEY (id)
>> );
>>
>> CREATE INDEX foo_date_to_index
>>  ON foo
>>  USING btree
>>  (date_to)
>>
>> insert into foo (id, date_to) values (1, now());
>> insert into foo (id, date_to) values (2, NULL);
>>
>> select * from foo where date_to is null and date_to > '2011-01-01'
>>
>> Expected: 0 rows
>>
>> But: it return 1 row with id=2
>>

I get the same error on HEAD too. An even simpler test case is this:

create table foo(a int);
create index foo_a_idx on foo(a);
insert into foo values (10),(NULL);
select 1 from foo where a is null and a > 10000;

 ?column?
----------
        1
(1 row)

The problem seems to be in _bt_preprocess_keys(), which discards the
"a > 10000" predicate in favour of the "a is null" predicate on the
grounds that "null > 10000" in a nulls-last index.

It looks like a previous revision had the right check, based on the
logic that x IS NULL is incompatible with any other predicate.

Regards,
Dean

Attachment

pgsql-bugs by date:

Previous
From: "Marinos Yannikos"
Date:
Subject: Re: Ident authentication fails due to bind error on server (8.4.8)
Next
From: "Chris Bandy"
Date:
Subject: BUG #6080: information_schema.columns.column_default contains NULL inconsistently