Perry Smith wrote:
> Is any code page like iso-8859-1 or IBM850 different in the range
> that US-ASCII covers (from 0x00 to 0x7f)? If that is the case, then
> gnucash could change US-ASCII to practically anything.
Considering the character repertoire (i.e., that abstract set of
characters provided), then US ASCII is a subset of most character
repertoires. But considering the encoding (i.e., the binary
representation of the characters), then it is not a subset of most
encodings (e.g., not of UTF-8), but of some, such as the ISO 8859
series. So if your client application (e.g., gnucash) is sending its
data in US-ASCII, you can declare, say, ISO-8859-1 as the PostgreSQL
client encoding (assuming that US-ASCII is encoded in 8 bits, but we'll
take that as a given).
> The other question is about the cilent/server relationship. I'm
> assuming that gnucash is the client in this case.
Yes.
> It does set the
> locale (although it seems to do it incorrectly because eventually the
> locale gets blown away -- but thats another problem). But what about
> sorting. Is that done in the server or the client?
server
> If gnucash does
> a select with a order by phrase, the ordering is one in the server,
> right?
server
> If so, that would mean that the server needs to be told the proper
> encoding since that will effect the sort order.
No, the locale affects the sort order. The locale is set when the
database cluster is initialized by initdb and cannot be set by client
applications no matter how hard you try. The encoding merely has to
try to be compatible with that locale. (This is a mess, but it's a
result of somewhat incomplete OS functionality being replicated by
PostgreSQL.) So overriding the default server encoding is only going
to lead you to trouble because you cannot guarantee compatibility with
the locale.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
