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/
