Meetesh Karia <meetesh.karia@xxxxxxxxx> writes:
> Additionally, here's what I get when I run your test below (my server
> encoding is UTF-8):
> ltefull=# create table x (r varchar(255) unique);
> NOTICE: CREATE TABLE / UNIQUE will create implicit index "x_r_key" for
> table "x"
> CREATE TABLE
> ltefull=#
> ltefull=# set client_encoding=WIN1250;
> SET
> ltefull=# insert into x (r) values ('Daniel Brühl');
> INSERT 0 1
> ltefull=#
> ltefull=# insert into x (r) values ('Daniel Bruehl');
> ERROR: duplicate key value violates unique constraint "x_r_key"
You said this was on Windows, right?
I was about to say "that should be impossible", until I looked at
varstr_cmp() and realized that whoever put in the WIN32/UTF8
special case omitted this part:
/*
* In some locales strcoll() can claim that nonidentical strings are
* equal. Believing that would be bad news for a number of reasons,
* so we follow Perl's lead and sort "equal" strings according to
* strcmp().
*/
if (result == 0)
result = strcmp(a1p, a2p);
So we behave differently on Windows (with UTF8) than anywhere else.
This is pretty nasty, not least because it means that texteq is
inconsistent with other text comparison operators.
I think this is a "must fix" bug for 8.3.1, anyone disagree?
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
