From: | David Wheeler <david(at)kineticode(dot)com> |
---|---|
To: | Ian Barwick <barwick(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: UTF-8 and LIKE vs = |
Date: | 2004-08-23 21:46:40 |
Message-ID: | EB3ADE5B-F54D-11D8-990D-000A95972D84@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Aug 23, 2004, at 2:25 PM, Ian Barwick wrote:
> I don't know what the problem is, but you might want to check the
> client encoding settings, and the encoding your characters are
> arriving in (remembering all the time, in Postgres "UNICODE" really
> means UTF-8).
>
> If you're using Perl (I'm guessing this is Bricolage-related) the
> "_utf8_on"-ness of strings might be worth checking too, and also the
> "pg_enable_utf8" flag in DBD::Pg.
Bricolage is getting all its content at UTF-8. It has been working
beautifully for some time. I tried setting the utf8 flag on the
variable passed to the query, but it made no difference.
I think that LIKE is doing the right thing, and = is not. And I need to
find out how to get = to do the right thing. If I need to dump my
database and run initdb to use C for LC_COLLATE, the, feh, I will.
Right now I have:
LC_COLLATE: en_US.UTF-8
LC_CTYPE: en_US.UTF-8
Regards,
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Wheeler | 2004-08-23 21:47:01 | Re: UTF-8 and LIKE vs = |
Previous Message | Robert Treat | 2004-08-23 21:31:26 | Re: UTF-8 and LIKE vs = |