Re: Bug in row_number() optimization

Поиск
Список
Период
Сортировка
От Sergey Shinderuk
Тема Re: Bug in row_number() optimization
Дата
Msg-id 56237b3b-67d9-09ba-aec2-c5fa457829fe@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Bug in row_number() optimization  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Bug in row_number() optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 25.11.2022 15:46, Richard Guo wrote:
> Considering the 'Filter' is a strict function, marking it as
> NULL would do.  I think this is why this patch works.

What about user-defined operators? I created my own <= operator for int8 
which returns true on null input, and put it in a btree operator class. 
With my operator I get:

   depname  | empno | salary | enroll_date | c1 | rn | c2 | c3
-----------+-------+--------+-------------+----+----+----+----
  personnel |     5 |   3500 | 2007-12-10  |  2 |  1 |  2 |  2
  sales     |     3 |   4800 | 2007-08-01  |  3 |  1 |  3 |  3
  sales     |     4 |   4800 | 2007-08-08  |  3 |    |    |  3
(3 rows)

Admittedly, it's weird that (null <= 1) evaluates to true. But does it 
violate  the contract of the btree operator class or something? Didn't 
find a clear answer in the docs.

-- 
Sergey Shinderuk        https://postgrespro.com/




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ted Yu
Дата:
Сообщение: checking rd_rules in RelationBuildDesc
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Non-decimal integer literals