Tom Lane wrote:
Yes it does, and you missed the point. I said *locale*, not *encoding*.
The LC_COLLATE and LC_CTYPE settings that prevail during initdb are
fixed and not alterable without re-initdb. (I agree that this sucks,
but that's how it is for now...)
You're right. After using:
initdb --l
Kent Tong <[EMAIL PROTECTED]> writes:
> Does it matter? The encoding provided to initdb is just
> a default for the databases to be created in the future.
Yes it does, and you missed the point. I said *locale*, not *encoding*.
The LC_COLLATE and LC_CTYPE settings that prevail during initdb are
fi
Tom Lane wrote:
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
Description:Two different Unicode chars are treated as equal in a
query
This would be a matter to take up with the maintainer of your locale
(which you didn't mention, but in any case it's a locale bug). We
just do what
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Description:Two different Unicode chars are treated as equal in a
> query
This would be a matter to take up with the maintainer of your locale
(which you didn't mention, but in any case it's a locale bug). We
just do what strcoll() te
The following bug has been logged online:
Bug reference: 1268
Logged by: Kent Tong
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.5
Operating system: RedHat 9
Description:Two different Unicode chars are treated as equal in a
query
Details:
Steps:
1.
