FreeTDS Development Group

[Steve Langasek <vorlon AT dodds.net>]

On Sat, Apr 01, 2006 at 01:32:13PM -0500, James K. Lowden wrote:

> 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?  

SUSv2 defines nl_langinfo() to return:

  In a locale where langinfo data is not defined, nl_langinfo() returns a
  pointer to the corresponding string in the POSIX locale. In all locales,
  nl_langinfo() returns a pointer to an empty string if item contains an
  invalid setting.

  <http://www.opengroup.org/onlinepubs/007908799/xsh/nl_langinfo.html>

Under what circumstances/on what platform do you see nl_langinfo(CODESET)
returning 'CCCCCCCC'?  That seems an unusual name for a codeset.  It's true
that SUSv2 doesn't seem to require that nl_langinfo(CODESET) be a valid
encoding name recognized by iconv_open(); I'm certain this is the case with
glibc, but it doesn't seem to be guaranteed by any standards.

But this is precisely why the latest version of my patch allows you to
specify an alternate charset for a given locale, overriding the one derived
from the environment.  Any value retrieved from nl_langinfo() takes
precedence over a client charset specified in a [default] section of
locales.conf, and any per-locale setting specified in locales.conf takes
precedence in turn over the system-provided value.

Oops.  I realize now that in my previous message I wrote:

> 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

In truth, this is neither what I think, nor what the patch does. :)  The
actual order implemented by the patch is:

- per-database client charset setting from /etc/freetds/freetds.conf
- per-locale client charset setting from /etc/freetds/locales.conf
- locale-derived client charset setting
- default client charset setting from /etc/freetds/locales.conf

Do you consider this reasonable?  I'm not bothered if locale-derived
settings end up at the bottom, I'll just keep an empty locales.conf in that
case anyway. :)  I think in general, overriding the client charset on a
per-database level is going to be more important than overriding on a
per-locale level anyway, since people are likely to connect to lots of
databases using, e.g., a single apache process with a locale of C and want
to have different client charset handling for each.

> 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?  

I'm not sure why special values such as these would be needed in
freetds.conf.  I think the above precedence rules are sufficient, whether or
not nl_langinfo is ranked above locales.conf/[default].

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon AT debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature