On Thu, Apr 03, 2008 at 06:54:50PM +0100, Gregory Stark wrote:
> The big gotcha is what collation to use when comparing with data in the system
> tables, especially the shared system tables. I think we do need to define a
> database-wide encoding and collation to use for system tables. (Unless we can
> get by with varchar_pattern_ops indexes on system tables?)
In my version I simply made that all system tables were in locale C,
standard binary sorting. Anything else is likely to blowup if you want
to start using multiple encodings. From a performance point of view
this is best, since you don't want the planner bogging down because the
user wants an expensive collation.
> b) They're using multiple collations for their data but only one "at a time".
> Either one per database or one per session. In which case they don't incur any
> overhead
The case I'm thinking of if people wanting some columns to be
case-insensetive. I'm not sure however if this will be in the first
version though.
Also, there isn't one-to-one correspondence between locales and
collations. There are many more collations and I hope we will support
that. The common variations are ascending/descending and
case-sensetivity.
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.
