FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Steve, 

Steve Langasek wrote:
> Bottom line is, I don't want to have to twiddle files in /etc/freetds/
> in order to get sqsh to display its output in my configured character
> set when this should be completely unnecessary.

Agreed.  

> So I think the order of preference for charset configuration should be,
> from highest to lowest:
> 
> - per-database client charset setting from /etc/freetds/freetds.conf
> - locale-derived client charset setting
> - per-locale client charset setting from /etc/freetds/locales.conf
> - default client charset setting from /etc/freetds/locales.conf

Here's my problem:

+       if ((s = nl_langinfo(CODESET))) {

Will s always be valid/useful when it isn't NULL?  What if the string is
'CCCCCCCC', or somesuch, as it often is?  Should that then supersede
locales.conf?  

Basically, I don't know when to trust the return for nl_langinfo(3). I
don't know if the admin has set up the environment correctly, and I don't
know if the application has called setlocale(3).  Therefore, I need a
flexible way to let the user declare his charset, in case nl_langinfo
doesn't Just Work.  

So, I think the order should be:

freetds.conf [server]
freetds.conf [global]
nl_langinfo
locales.conf

If nothing about charsets appears in freetds.conf, then we use nl_langinfo
(if available).  To override that, the user would set a special value in
freetds.conf, something like:

        client charset = LC_LANG
or      client charset = locales.conf

I take it your patch gets us partway there.  Do you agree this is a good
solution?  

Regards, 

--jkl