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

Re: Encoding problems with migration from 8.0.14 to 8.3.0 on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: meetesh(dot)karia(at)alumni(dot)duke(dot)edu
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-admin(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Encoding problems with migration from 8.0.14 to 8.3.0 on Windows
Date: 2008-03-13 15:43:22
Message-ID: 17759.1205423002@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackers
Meetesh Karia <meetesh(dot)karia(at)gmail(dot)com> 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 Brhl');
> 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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-03-13 15:52:17
Subject: Re: Nasty bug in heap_page_prune
Previous:From: Gregory StarkDate: 2008-03-13 14:25:19
Subject: aclitem out/in don't "work"

pgsql-admin by date

Next:From: Tom LaneDate: 2008-03-13 16:04:27
Subject: Re: migration of 7.4 to 8.1
Previous:From: Tom LaneDate: 2008-03-13 15:31:36
Subject: Re: LAN connection to server only after restart server

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