Re: BUG #6079: Wrong select result
От | Dean Rasheed |
---|---|
Тема | Re: BUG #6079: Wrong select result |
Дата | |
Msg-id | BANLkTikwdP9utpjNTb9p7SmBJf57KPFMtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6079: Wrong select result (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: BUG #6079: Wrong select result
|
Список | 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
Вложения
В списке pgsql-bugs по дате отправления: