Re: evil characters #bfef cause dump failure

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

In response to

Browse pgsql-admin by date

  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'