On Sat, Oct 18, 2008 at 11:28:41AM -0400, Tom Lane wrote:
> 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".
It's hardly string specific. At least geometric types have the concept
of multiple collations. Any datatype can have a set of useful
collations, I'd hate to restrict this to just strings.
> 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?)
Well, the standard has plenty of disscussion about that. If the
operator is a comparison the two collations must be coerible to the
same collation. If it's not and the result type isn't text then it
doesn't matter. And if the result is text then you mark it as ambiguous
and thus require the user to specify explicitly.
> 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.
I think the storage space considerations make that a difficult option.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.