| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ken Benson <ken(at)infowerks(dot)com> |
| Cc: | pgsql-novice(at)postgresql(dot)org |
| Subject: | Re: Re: [NOVICE] Problems with ñ and tildes / CSV import problems in PostgreSQL 9.1 |
| Date: | 2013-02-07 16:15:27 |
| Message-ID: | 13305.1360253727@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-novice |
Ken Benson <ken(at)infowerks(dot)com> writes:
> So - the problem may be that /*truly**0x e1 73 71*/ is not a valid UTF-8
> character in the current iteration of PostgreSQL - or at all.
Of course it isn't, which is why Postgres is complaining. Presumably
what that data really is is three characters (looks like "sq") in
LATIN1. But Postgres is trying to interpret it in UTF8. As mentioned
upthread, the solution is to adjust the client_encoding setting before
running the COPY command.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-02-07 16:26:48 | Re: feature requests (possibly interested in working on this): functional foreign keys |
| Previous Message | Zach Seaman | 2013-02-07 16:01:28 | Re: [NOVICE] Problems with ñ and tildes / CSV import problems in PostgreSQL 9.1 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zach Seaman | 2013-02-07 16:51:23 | Re: [NOVICE] Re: [NOVICE] Problems with ñ and tildes / CSV import problems in PostgreSQL 9.1 |
| Previous Message | Zach Seaman | 2013-02-07 16:01:28 | Re: [NOVICE] Problems with ñ and tildes / CSV import problems in PostgreSQL 9.1 |