Tom Lane napisał(a):
It was discussed a week or two ago. We're still testing a patch, but
in the meantime you can work around it by making sure that the
postmaster is started with environment variables LC_COLLATE and LC_CTYPE
matching the settings used in the database.
It seems to work. Th
Robert Osowiecki <[EMAIL PROTECTED]> writes:
> Yes, I am. Where can I read about that other problem, especially: does
> plperl spoil locale with each pgperl function call or only when creating
> language?
It was discussed a week or two ago. We're still testing a patch, but
in the meantime you c
Tom Lane napisal:
Robert Osowiecki <[EMAIL PROTECTED]> writes:
Hm, are you using any plperl functions? This could be the same problem
already identified with plperl messing up the locale settings.
Yes, I am. Where can I read about that other problem, especially: does
plperl spoil locale
Tom Lane napisał(a):
"Robert Osowiecki" <[EMAIL PROTECTED]> writes:
BUT when on "where ar_code = 'FOO'" unique_code_i index is used and query
returns NO ROWS!
Could you be more specific? Which values of 'FOO' does this happen for?
I haven't checked for everyone. I'll be doing an
"Robert Osowiecki" <[EMAIL PROTECTED]> writes:
> BUT when on "where ar_code = 'FOO'" unique_code_i index is used and query
> returns NO ROWS!
Could you be more specific? Which values of 'FOO' does this happen for?
What is the datatype of ar_code? If it's a string type, what locale and
encoding
On 1/4/06, Robert Osowiecki <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2143
> Logged by: Robert Osowiecki
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.1.1
> Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 2
The following bug has been logged online:
Bug reference: 2143
Logged by: Robert Osowiecki
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.1
Operating system: Linux 2.6.14-gentoo-r5 #2 SMP Thu Dec 22 11:58:01 CET
2005 i686 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel G
