Skip site navigation (1) Skip section navigation (2)

Re: Open issues for collations

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Open issues for collations
Date: 2011-03-28 20:40:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-03-28 20:47:06
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Previous:From: Peter EisentrautDate: 2011-03-28 20:18:16
Subject: Re: WIP: Allow SQL-language functions to reference parameters by parameter name

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group