On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
> * RI triggers should insert COLLATE clauses in generated queries to
> satisfy SQL2008 9.13 SR 4a, which says that RI comparisons use the
> referenced column's collation. Right now you may get either table's
> collation depending on which query type is involved. I think an obvious
> failure may not be possible so long as equality means the same thing in
> all collations, but it's definitely possible that the planner might
> decide it can't use the referenced column's unique index, which would
> suck for performance. (Note: this rule seems to prove that the
> committee assumes equality can mean different things in different
> collations, else they'd not have felt the need to specify.)
Right, but we don't support that yet, so I don't consider that that has
to be addressed right now. Rather it could go on a "list of things to
fix when supporting collations which redefine equality". The index
mismatch issue is also not urgent. It's not a regression and it's more
like don't-do-that-then or do-it-differently-then.
> * It'd sure be nice if we had some nontrivial test cases that work in
> encodings besides UTF8. I'm still bothered that the committed patch
> failed to cover single-byte-encoding cases in upper/lower/initcap.
Well, how do we want to maintain these test cases without doing too much
duplication? It would be easy to run a small sed script over
collate.linux.utf8.sql to create, say, a latin1 version out of it.
Since it's Linux only, it might be valid to do it that way without
having to make it super-portable in C.
> * Remove initdb's warning about useless locales? Seems like pointless
> noise, or at least something that can be relegated to debug mode.
Fine with me.
> * Is it worth adding a cares-about-collation flag to pg_proc? Probably
> too late to be worrying about such refinements for 9.1.
Probably. It would open up a bunch of new cases to change and
fine-tune.
