> I'd be inclined to handle it similarly to the way that Tatsuo did with
> conversion_procs: let collations be represented by comparison functions
> that meet some suitable API. I think that trying to represent such a
> table as an SQL table compactly will be a nightmare, and trying to
> access it quickly enough for reasonable performance will be worse. Keep
> the problem out of the API and let each comparison function do what it
> needs to do internally.
Agreed. That was the way I have been thinking about collation/create
character stuff too.
--
Tatsuo Ishii