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

From Andrey Borodin
Subject Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX
Date
Msg-id 555D8E05-CAB6-445E-A333-5B1E86207266@yandex-team.ru
Whole thread Raw
In response to Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PG-11] Potential bug related to INCLUDE clause of CREATE INDEX  (Yugo Nagata <nagata@sraoss.co.jp>)
List pgsql-hackers
Hi!

> 10 июля 2018 г., в 17:54, Tom Lane <tgl@sss.pgh.pa.us> написал(а):
>
> Aditya Toshniwal <aditya.toshniwal@enterprisedb.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"
testaltogether, 
> 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
stepsthat seem useful: e.g. "ERROR:  including column does not support ASC/DESC options" and "ERROR:  including column
doesnot 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.

pgsql-hackers by date:

Previous
From: Alexander Kuzmenkov
Date:
Subject: Re: [HACKERS] PoC: full merge join on comparison clause
Next
From: Peter Eisentraut
Date:
Subject: Re: Let's remove DSM_IMPL_NONE.