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)
Yes
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
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
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 w
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 first
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 fir
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
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 mean
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
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 case-in
11 matches
Mail list logo
