On Thu, Apr 12, 2018 at 1:14 AM, Teodor Sigaev <teo...@sigaev.ru> wrote:
> Peter Geoghegan wrote: > >> On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut >> <peter.eisentr...@2ndquadrant.com> wrote: >> >>> But in this case it doesn't even do equality comparison, it just returns >>> the value. >>> >> >> That's the idea that I tried to express. The point is that we need to >> tell the user that there is no need to worry about it, rather than >> that they're wrong to ask about it. Though we should probably actually >> just throw an error. >> > > Any operation over including columns is a deal for filter, not an index, > so collation will not be used somewhere inside index. > > 2Alexander: ComputeIndexAttrs() may use whole vectors (for including > columns too) just to simplify coding, in other places, seems, better to > have exact size of vectors. Using full-sized vectors could mask a error, > for exmaple, with setting opfamily to InvalidOid for key column. But if you > insist on that, I'll modify attached patch to use full-sized vectors > anywhere. > > In attached path I did: > 1) fix a bug in CompareIndexInfo() which checks opfamily for including > column > 2) correct size for all vectors > 3) Add assertion in various places to be sure that we don't try to use > including column as key column > 4) per Peter Geoghegan idea add a error message if somebody adds options > to include column instead silently ignore it. I don't insist on using full-sized vectors everywhere. Attached patch looks OK for me. I haven't test it though. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
