Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > It's quite straightforward. Every expression has a collation, the COLLATE > keyword just overrides it. And the collation is a parameter of the > operators/functions that want to use it. Implementation is also > straightforward: add expr :: expr COLLATE ident to the bison code and a > collation oid to the Expr node.
It's fairly irritating to think that a string-specific option is going to become part of the fundamental type system --- it makes no sense to distinguish different collations for numeric for instance (and in fact I would want to see the parser throw an error if you tried to attach a collation to a non-string type). As for inserting a collation OID in every single variant of Expr, the answer is "no". Another objection to this design is that it's completely unclear that functions from text to text should necessarily yield the same collation that went into them, but if you treat collation as a hard-wired part of the expression syntax tree you aren't going to be able to do anything else. (What will you do about functions/operators taking more than one text argument?) I think it would be better to treat the collation indicator as part of string *values* and let it bubble up through expressions that way. The "expr COLLATE ident" syntax would be a simple run-time operation that pokes a new collation into a string value. The notion of a column having a particular collation would then amount to a check constraint on the values going into the column. 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