FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno sab, 01/04/2006 alle 13.49 -0800, Steve Langasek ha scritto:
> 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.
> 

If I remember HP-UX returns "C C C". However we have a table of all
charset so we can ignore "garbage".

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

I think we all agree to have client_charset in TDSLOCALE. At least ABI
we can make this ABI change before RC3...

> > 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].
> 

I think we wrote locales.conf to handle strange system configuration
where we can't get charset from nl_langinfo/whatever. For instance is
not really needed in Linux where nl_langinfo return wanted charset. I
think also that char_set is less important cause now FreeTDS can compute
proper value from client_charset.

I don't find nothing wrong having the possibility to choose precedence,
for instance one could fill freetds.conf/locales.conf in order to suite
different systems.

I think we all agree that current implementation lack support of
nl_langinfo

freddy77