On Fri, Sep 08, 2006 at 11:58:59AM +0100, Heikki Linnakangas wrote:
> Martijn van Oosterhout wrote:
> >I think that if SQL COLLATE gets in we'll get this almost for free.
> >Collation and charset are both properties of strings. Once you've got a
> >mechanism to know the collation of a string, you just attach the
> >charset to the same place. The only difference is that changing charsets
> >requires recoding, wheres changing collation does not.
>
> Not quite. Collation is a property of the operation that you're doing.
> For example, if you're doing a sort, you might do it in different
> collation depending on the user that's doing it, or it might even be
> chosen by the user case-by-case. Of course, usually you have a default
> set per-database, per-table or per-column, but it's not a property of
> the actual value of a field. I think that the phrase "collation of a
> string" doesn't make sense.
Sorry, you're quite right. The collation is the property of an executor
node, or at least that's how I thought of it while I was working on it.
By that I mean that each source (say column) has a defined value for
collation and charset (the SQL defines the rules for determining
collation, don't know about charset). At each point in the query you
can point at the charset and collation applying to that node.
However, I think my point that charset and collations could be treated
via the same mechanism is still valid. If I get time I might rework the
COLLATE spec I wrote to include charset stuff.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.