From: | Christian Fowler <spider(at)viovio(dot)com> |
---|---|
To: | pgsql-admin list <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: evil characters #bfef cause dump failure |
Date: | 2004-11-16 16:06:50 |
Message-ID: | Pine.LNX.4.61.0411161057120.16733@leda.steelsun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I strongly agree with this. I have always been uncomfortable selecting
"UNICODE" and never quite sure if it is the UTF8, UTF16, or UTF32
encoding.
SQL_8BIT or SQL_RAW make much more sense than SQL_ASCII given that Tom
said this is a lack of encoding. I fear I might have high-bits chopped off
or something.
However, back to my problem... if a #bfef character is shoved into a
VARCHAR, one's dump is hosed. If I went to various websites and entered
this in, I could cause a lot of pain. I believe I noticed some characters
(like new line and tab) are converted to <80> or similar. Could/should
this be extended to more character ranges - particularly high byte chars
for people with the SQL_ASCII (lackof) encoding?
On Tue, 16 Nov 2004, Markus Bertheau wrote:
>
> This is, by the way, a reason why this encoding should be renamed to
> SQL_8BIT (or something along these lines) and UNICODE to UTF-8.
>
> --
> Markus Bertheau <twanger(at)bluetwanger(dot)de>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
[ \ /
[ >X< Christian Fowler | spider AT viovio.com
[ / \ http://www.viovio.com | http://www.tikipro.org
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Chapman | 2004-11-16 16:51:48 | How to use custom functions created by my2pg.pl? |
Previous Message | Francisco Jose Bernabe Pellicer | 2004-11-16 12:28:52 | Query failed: ERROR: Unable to identify an operator '=' for types 'character varying' and 'character' |