Martijn van Oosterhout <klep...@svana.org> writes: > On Mon, Mar 07, 2011 at 11:43:20AM -0500, Tom Lane wrote: >> Is there any documentation of $SUBJECT?
> 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. OK. > 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. Only if the expression-to-be-sorted does not already fully specify the collation, which so far as I can tell (either from the code or your description above) it does. I think that the explicit representation of collation as part of the PathKey node is unnecessary, inefficient, and bug-inducing --- the latter because it promotes fuzzy thinking about where the collation information is coming from. (And this isn't just hypothetical: IMO the bugs I exhibited upthread are *directly* due to fuzzy thinking about what defines an index's sort order.) Or, to put it another way: the properties that define a sort order are the sort comparison operator, the collation, the ASC/DESC bit, and the NULLS FIRST/LAST bit. Given the way that the SQL committee has constructed the language, the operator and the two flag bits are attached to the ORDER BY clause, but the collation is a property of the expression-to-be-sorted. If we fail to preserve that distinction in the internal representation, we're just creating problems for ourselves. I'm willing to take a pass at fixing this code during the alpha cycle, but I want to be sure I understand it correctly first. So, if there's a hole in my thinking, please point it out. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers