From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Renat <renat(dot)nasyrov(at)itv(dot)ru>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6079: Wrong select result |
Date: | 2011-06-28 21:45:45 |
Message-ID: | BANLkTikwdP9utpjNTb9p7SmBJf57KPFMtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> 2011/6/28 Renat <renat(dot)nasyrov(at)itv(dot)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 | Content-Type | Size |
---|---|---|
nbtutils.patch | application/octet-stream | 649 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Hodder | 2011-06-29 06:56:40 | BUG #6081: trigger CRUD log entries, or documentation not clear that triggers do not log |
Previous Message | Marinos Yannikos | 2011-06-28 21:02:58 | Re: Ident authentication fails due to bind error on server (8.4.8) |