alexander,
lc_ctype and lc_collate can be changed only at initdb !
You need to read localization chapter
http://www.postgresql.org/docs/current/static/charset.html
Oleg
On Thu, 12 Jul 2007, alexander lunyov wrote:
Tom Lane wrote:
alexander lunyov [EMAIL PROTECTED] writes:
With this i
Oleg Bartunov wrote:
alexander,
lc_ctype and lc_collate can be changed only at initdb !
You need to read localization chapter
http://www.postgresql.org/docs/current/static/charset.html
Yes, i knew about this, but i thought maybe somehow it can be changed
onthefly.
... (10 minutes later)
Tom Lane wrote:
alexander lunyov [EMAIL PROTECTED] writes:
With this i just wanted to say that lower() doesn't work at all on
russian unicode characters,
In that case you're using the wrong locale (ie, not russian unicode).
Check show lc_ctype.
db= SHOW LC_CTYPE;
lc_ctype
--
On Tue, Jul 10, 2007 at 08:40:24AM +0400, alexander lunyov wrote:
Just to clarify: lower() on both sides of a comparison
should still work as expected on multibyte encodings ? It's
been suggested here before.
lower() on both sides also does not working in my case, it still search for
Karsten Hilbert wrote:
Just to clarify: lower() on both sides of a comparison
should still work as expected on multibyte encodings ? It's
been suggested here before.
lower() on both sides also does not working in my case, it still search for
case-sensitive data. String in this example have
alexander lunyov [EMAIL PROTECTED] writes:
With this i just wanted to say that lower() doesn't work at all on
russian unicode characters,
In that case you're using the wrong locale (ie, not russian unicode).
Check show lc_ctype.
Or [ checks back in thread... ] maybe you're using the wrong
Hello, friends.
OS FreeBSD 6.2, Postgresql 8.2.4
Postgresql does not search case-insensitive russian regexp unicode
patterns. Postgres is working under user pgsql with login class (in
/etc/login.conf):
postgres:\
:lang=ru_RU.UTF-8:\
:setenv=LC_COLLATE=C:\
:tc=default:
In
No, ILIKE also does case-sensitive search.
I found this bug report:
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00065.php
Is it about this issue? And will it be fixed someday?
Sergey Levchenko wrote:
Just use: select street from people where street ILIKE 'зелен%';
select with
On Mon, Jul 09, 2007 at 04:00:01PM +0400, alexander lunyov wrote:
I found this bug report:
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00065.php
Is it about this issue?
Yes.
And will it be fixed someday?
Likely. In the meantime lower() can come to the rescue.
Karsten
--
GPG key
Karsten Hilbert [EMAIL PROTECTED] writes:
On Mon, Jul 09, 2007 at 04:00:01PM +0400, alexander lunyov wrote:
I found this bug report:
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00065.php
Is it about this issue?
Yes.
And will it be fixed someday?
Likely. In the meantime lower()
On Mon, Jul 09, 2007 at 09:50:42AM -0400, Tom Lane wrote:
On Mon, Jul 09, 2007 at 04:00:01PM +0400, alexander lunyov wrote:
I found this bug report:
http://archives.postgresql.org/pgsql-bugs/2006-09/msg00065.php
Is it about this issue?
Yes.
And will it be fixed someday?
Likely.
Karsten Hilbert wrote:
Just to clarify: lower() on both sides of a comparison
should still work as expected on multibyte encodings ? It's
been suggested here before.
lower() on both sides also does not working in my case, it still search
for case-sensitive data. String in this example have
12 matches
Mail list logo
