Perry Smith pedz at
Tue Jul 20 12:14:33 EDT 2004

The postgres backend basically creates a statement to send to postgres 
to create the database.  It pieces this statement together and one part 
is to get the value of nl_langinfo(CODESET) and append "... ENCODING %s 
..." where %s is the value from nl_langinfo.  The code right now, 
returns "" on my Mac OS  X system (10.3.4).  I fiddled with it and 
managed to get it to return "US-ASCII" but postgres rejects this value 
as well.  There is also compile time options to force the value of 

So I dug into the postgres code and it does not have a US-ASCII 
encoding.  It has such things as iso-8859-1, etc.  It points to an RFC 
in the comments.  Looking at the RFC, it mentions US-ASCII as an alias 
to another code page but I can't deduce which one.  The reference is in 
some weird code that I did not take the time to figure out.

Also, I dug through all the IBM code and it never returns "US-ASCII".  
All this makes sense since it is not really a code page by modern 

So, I'm looking for suggestions on how to fix this.  I could just 
remove the "ENCODING %s" part under the assumption that postgres will 
encode the database based upon the LANG settings.  May as well let it 
guess what encoding rather than gnucash guessing -- there is no way to 
specify the encoding externally.

Another choice is to twist the US-ASCII encoding into something else 
(if nl_langinfo returns US-ASCII, replace it with XYZ.)  But I'm not 
sure of a great value for XYZ.

The third approach (get ready to laugh) is to pester Apple into fixing 
their code since it definately appears to be not up to the latest 
standards.  "Latest" in this case is pretty old as well.

Thanks for your help and suggestions,

More information about the gnucash-devel mailing list