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

Reply via email to