Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX
Date: 2018-07-10 16:37:49
Message-ID: 555D8E05-CAB6-445E-A333-5B1E86207266@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

> 10 июля 2018 г., в 17:54, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал(а):
>
> Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com> writes:
>> I am working on a feature to support INCLUDE clause of index in PG-11. As
>> per the documentation https://www.postgresql.org/docs/11/static/
>> sql-createindex.html, columns listed in INCLUDE clause cannot also be
>> present as index key columns. But I find different behaviour for below
>> queries which are logically identical.
>
> I wonder why there is any such restriction at all. We have never
> attempted to prevent the creation of "silly" indexes [...] So my inclination is to rip out the "must not intersect" test altogether,
> not try to make it a bit smarter

It seems to me valid way of reaching the completely consistent validation behavior. But there are some other validation steps that seem useful: e.g. "ERROR: including column does not support ASC/DESC options" and "ERROR: including column does not support NULLS FIRST/LAST options".

IMHO it is not a bug. CREATE INDEX ON some_table(id+0) INCLUDE (id); or some similar tricks will work anyway.

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-07-10 16:52:54 Re: Let's remove DSM_IMPL_NONE.
Previous Message Alexander Kuzmenkov 2018-07-10 16:36:56 Re: [HACKERS] PoC: full merge join on comparison clause