I think the collations patch has now gone about as far as it's going to
get for 9.1. There are a couple of areas that ought to be on the TODO
list for future versions, though:
* Integrating collations with text search configurations. There are
several places in the tsearch code that currently have hard-wired uses
of DEFAULT_COLLATION_OID to control case-folding and character
classification behavior. The most obvious way to generalize that would
be to have the tsearch operators/functions respond to COLLATE, but it
seems to me that that's likely a bad idea --- the appropriate collation
to use for these behaviors needs to be tied to the active text search
dictionary or configuration, probably. Or maybe we should reverse that
and extend the notion of a collation object to include a reference to a
text search configuration. It needs thought. One other point is that
we can't easily put a collation selection into tsearch configurations
so long as collation names are platform-specific. Should we have a TODO
item to find a way of providing platform-independent collation names?
* Integrating collations with to_char() and related functions. Their
current behavior is a bit schizophrenic, in that things like TMMonth
will do case-folding according to the function's input COLLATE property,
but the month name itself is determined according to the LC_TIME GUC.
Not sure if we should extend the notion of a collation to cover all
of the LC_foo categories --- if we do, we'll have to think about the
interaction with the legacy GUC variables.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
