From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | j n <jneuschld(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: can i use to_ascii function ? |
Date: | 2007-02-26 15:25:24 |
Message-ID: | 20070226152524.GA86963@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
[Once again, please copy the mailing list on replies so others can
participate in and learn from the discussion. Also, pgsql-general
might be a more appropriate list than pgsql-admin.]
On Mon, Feb 26, 2007 at 10:53:48AM +0100, j n wrote:
> 1. At first i tried use to_ascii ... convert
> it works well on some letter 'á' converted to 'a' 'é' to 'e' but some of
> them like č or š convert as empty string it means 'not working fine'
We can't explain why this doesn't work unless you show exactly what
you did. Please post a set of SQL statements that somebody could
run in their own database to reproduce the problem you're seeing.
Did any of this data originate on Windows? If so then it's possible
that some accented characters aren't represented by the proper
Unicode code points. This can happen, for example, if you load
Windows-1250 data into the database with client_encoding set to
LATIN2. Depending on how you're viewing the data the "wrong"
characters might still display correctly. To give a specific
example, š is 0x9a in Windows-1250 but if you load this character
with client_encoding set to LATIN2 then the database converts it
to U+009A, a control character, instead of to U+0161 latin small
letter s with caron (háček). An application that reads the control
character might render it as š assuming that that's what character
was meant, but functions that operate on the data won't work as
expected. This wouldn't fully explain the problems you're seeing
but it's something I've seen cause similar problems.
> 2. than i tried to use perl func but i didn't have configured postgres to
> use perl so i have to :
>
> ./configure --enable-multibyte=UTF8 prefix=/usr/local/pgsqlProd
> --exec-prefix=/usr/local/pgsqlProd --with-perl
The --enable-multibyte option was removed in 7.3 so you don't need
it; at the end of the configure you should have seen a warning that
this option was ignored. And did you mean --prefix instead of
prefix? Also, there's no need to set --exec-prefix if it gets the
same value as --prefix.
> gmake
> gmake install
>
> 3. After this everythink have started to work fine also unaccent perl
> function ...
Configuring with --with-perl is necessary if you want to use server-
side Perl functions, but you didn't say anything about Perl functions
in your previous message. You said that to_ascii() and convert()
didn't work unless you used --with-perl, which doesn't make sense
because those functions have nothing to do with Perl. I tried it
both ways and got the same behavior so I'm still skeptical that
--with-perl is the relevant difference for to_ascii() and convert()
behavior.
--
Michael Fuhr
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Neyman | 2007-02-26 15:28:57 | host name? |
Previous Message | Antje.Stejskal | 2007-02-26 13:57:16 | Recovery/Rollback question |