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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
