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.
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 |