Skip site navigation (1) Skip section navigation (2)

Re: evil characters #bfef cause dump failure

From: Markus Bertheau <twanger(at)bluetwanger(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Iain <iain(at)mst(dot)co(dot)jp>, Christian Fowler <spider(at)viovio(dot)com>,pgsql-admin list <pgsql-admin(at)postgresql(dot)org>
Subject: Re: evil characters #bfef cause dump failure
Date: 2004-11-16 08:37:01
Message-ID: 1100594222.3393.0.camel@fc3 (view raw or flat)
Thread:
Lists: pgsql-admin
В Пнд, 15/11/2004 в 20:34 -0500, Tom Lane пишет:
> "Iain" <iain(at)mst(dot)co(dot)jp> writes:
> > It seems that this kind of thing pops up from time to time. I don't have v8 
> > available right now to check, but is SQL_ASCII still the default DB 
> > encoding? I'm wondering is unicode wouldn't be a better choice these days.
> 
> IIRC you can select the default encoding at build time, so this is
> really a question for packagers not the development team.
> 
> You make a good point though --- I'm a bit tempted to make it default to
> UNICODE for the Red Hat build, since Red Hat is pretty gung-ho on UTF8
> support these days.
> 
> BTW, SQL_ASCII is not so much an encoding as the absence of any encoding
> choice; it just passes 8-bit data with no interpretation.  So it's not
> *that* unreasonable a default.  You can store UTF8 data in it without
> any problem, you just won't have the niceties like detection of bad
> character sequences.

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>


In response to

Responses

pgsql-admin by date

Next:From: IainDate: 2004-11-16 08:45:09
Subject: Re: evil characters #bfef cause dump failure
Previous:From: Peter EisentrautDate: 2004-11-16 07:18:53
Subject: Re: evil characters #bfef cause dump failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group