Skip to Content.
Sympa Menu

freetds - Re: [freetds] charset selection [was: 0.64rc2 Debian prerelease packages available]

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] charset selection [was: 0.64rc2 Debian prerelease packages available]
  • Date: Sun, 02 Apr 2006 09:00:33 +0200

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






Archive powered by MHonArc 2.6.24.

Top of Page