> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
