I think I understand but wanted to ask a few more questions.
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.
The other question is about the cilent/server relationship. I'm
assuming that gnucash is the client in this case. 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? If gnucash does a
select with a order by phrase, the ordering is one in the server,
right?
If so, that would mean that the server needs to be told the proper
encoding since that will effect the sort order.
Is that correct?
Thanks
Perry
On Jul 20, 2004, at 11:34 AM, Peter Eisentraut wrote:
> Perry Smith wrote:
>> I'm wondering how to solve this problem. Should a "usascii" alias be
>> added to encnames.c?
>
> Probably not, considering that PostgreSQL does not really support
> US-ASCII as such. (Supersets of US-ASCII are supported, but when you
> select a charset, you don't want a superset of that charset.)
>
>> Should gnucash change "US-ASCII" into something else?
>
> Yes.
>
>> Should I try and get Apple to change their code since it is
>> not really a code page?
>
> It is a code page (or an encoding, or a charset, or something or that
> sort). Several operating systems seem to agree.
>
>> Should I just remove the "ENCODING ..."
>> phrase from the command that gnucash creates to create a database
>
> I would probably create the database without an encoding specification
> and thus use the default encoding, since that will cooperate best with
> the character processing functions and the user's expectations in
> general. Gnucash should, like any client, set the client encoding to
> its actual encoding used on the frontend, and then the encoding used on
> the server side does not need to be of concern.
>
>> under the logic that postgres will using the encoding specified by
>> the LANG variable by default anyway (which I'm just guessing is what
>> it does)?
>
> No, scrap that logic. You need to set the client encoding yourself.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
>
