Re: Theory of operation of collation patch

On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote:
> Is there any documentation of $SUBJECT? Because the more I look at
> this patch the more I think it's misdesigned; either that or I
> fundamentally misunderstand what it's trying to do. I complained
> yesterday about why the planner wasn't using indcollation to identify
> the sort order of an index. I now think that the reason it doesn't
> obviously fail to fail is that indcollation is dead code, and so is
> approximately 99% of what you added to the planner, because two
> expressions that are equal() must necessarily have the same collation
> property. Tracking the collation as a separate property of a pathkey
> is thus a useless activity. If this conclusion isn't correct, please
> explain why not.

The collation is a property of the operators/functions and not of the
values. An individual value does not have a collation, a column does.

A pathkey represents a sort order, right? To define a sort order you
need a collation and so the path key is the natural place to put it.
Two path keys that differ only by the collation are *not* compatable,
but obviously can be converted by a sort node.

After the plan phase, the collation will be ignored in 99% of the
executer, except for operators like =, < and > that need to look at it.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle