Martijn van Oosterhout <kleptog@svana.org> 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