Re: 8.3 to 8.4 Upgrade issues - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.3 to 8.4 Upgrade issues
Date
Msg-id 3310.1281462581@sss.pgh.pa.us
Whole thread Raw
In response to 8.3 to 8.4 Upgrade issues  (Rod Taylor <rod.taylor@gmail.com>)
Responses Re: 8.3 to 8.4 Upgrade issues  (Rod Taylor <rod.taylor@gmail.com>)
List pgsql-hackers
Rod Taylor <rod.taylor@gmail.com> writes:
> Does anybody have experience on the cost, if any, of making this change?

> Pg 8.3:
> Encoding: SQL_ASCII
> LC_COLLATE: en_US
> LC_CTYPE: en_US

> Pg 8.4:
> Encoding: SQL_ASCII
> Collation: en_US.UTF-8
> Ctype: en_US.UTF-8

Well, *both* of those settings collections are fundamentally
wrong/bogus; any collation/ctype setting other than "C" is unsafe if
you've got encoding set to SQL_ASCII.  But without knowing what your
platform thinks "en_US" means, it's difficult to speculate about what
the difference between them is.  I suppose that your libc's default
assumption about encoding is not UTF-8, else these would be equivalent.
If it had been assuming a single-byte encoding, then telling it UTF8
instead could lead to a significant slowdown in strcoll() speed ...
but I would think that would mainly be a problem if you had a lot of
non-ASCII data, and if you did, you'd be having a lot of problems other
than just performance.  Have you noticed any change in sorting behavior?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Libpq: PQftype, PQfsize
Next
From: Robert Haas
Date:
Subject: Re: Session timeout on commitfest.postgresql.org