Re: encoding and LC_COLLATE

Hi Adrian,

You're right, i'm trying to get the copy command to put a load of data into
a table. It's now working fine except for any instances with an e acute

I tried putting " SET CLIENT_ENCODING TO 'UTF-8'; " but still got the error.
I guess that just because i'm verifying what's incoming, it doesn't mean
it's going to go into a database which doesn't support it?

Let me know if i'm missing something!

Cheers

Andy

From: Adrian Klaver-3 [via PostgreSQL]
[mailto:ml-node+s1045698n4991012h96(at)n5(dot)nabble(dot)com]
Sent: 14 November 2011 15:15
To: LPlateAndy
Subject: Re: encoding and LC_COLLATE

On Monday, November 14, 2011 3:03:32 am LPlateAndy wrote:

> Hi,
>
> I set up my postgres 9.0 install 6 months ago and generally everything is

> fine but a recent data load with an e acute character failed which an
> unsupported message which surprised me as we're using UTF-8.
>
> However, i can now see that the listing for the database set up show a
> restriction under LC_COLLATE and LC_CTYPE to the UK which would explain
the
> blocking of this character. Oddly, this is set even if i only specify
UTF-8
> which i guess means that it is set against the template. I can only assume

> that i selected this option on install but have since forgotten.
>
> CREATE DATABASE testing
> WITH OWNER = postgres
> ENCODING = 'UTF8'
> TABLESPACE = pg_default
> LC_COLLATE = 'English_United Kingdom.1252'
> LC_CTYPE = 'English_United Kingdom.1252'
> CONNECTION LIMIT = -1;
>
> Is there any way that i can change this, preferably against the template.
>
> If i try creating a new database by right clicking at the top of the
> database tree in pgAdmin i do note that i also have the options of "C" or
> "POSIX" but have read elsewhere that these are even more restrictive.
>
> Any ideas - hoping to avoid a complete re-install!

See:
http://www.postgresql.org/docs/9.0/interactive/multibyte.html#MULTIBYTE-CHAR
SET-
SUPPORTED

22.2.3. Automatic Character Set Conversion Between Server and Client

I am going to assume that the data load is the COPY you mentioned in the
other
post. Before doing the COPY use one of the methods shown in the link above
to
set the incoming encoding. This of course depends on you knowing what the
encoding is of the data you are importing:)

>
> Thanks in advance
>
> Andy
>
>

--
Adrian Klaver
[hidden email]

--
Sent via pgsql-general mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

_____

If you reply to this email, your message will be added to the discussion
below:

http://postgresql.1045698.n5.nabble.com/encoding-and-LC-COLLATE-tp4990415p49
91012.html

To unsubscribe from encoding and LC_COLLATE, click here
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsu
bscribe_by_code&node=4990415&code=YW5keUBjZW50cmVtYXBzLmNvLnVrfDQ5OTA0MTV8LT
E3NDM2MTI2> .
See how NAML generates this email
<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macr
o_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.B
asicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.templ
ate.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-in
stant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://postgresql.1045698.n5.nabble.com/encoding-and-LC-COLLATE-tp4990415p4991287.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.