FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno dom, 16/04/2006 alle 14.01 -0400, James K. Lowden ha scritto:
> Steve Langasek wrote:
> > > I think I recognize Steve's patch?  
> > 
> > Yeah, this is the Bad version of the patch that shipped in sarge as
> > well. :/ The only chance to fix this for Dapper is probably to ask the
> > Ubuntu maintainer to pull the patch, since the freeze for Dapper is upon
> > us; for etch and for Dapper+1 I'd like to see freetds 0.64 released with
> > the fixed version of the locale patch that I proposed on the list.
> 
> Steve, 
> 
> Thanks for weighing in.  I think I'm slowly getting it.  
> 
> You and Frediano both suggest applying your patch to 0.64.  I think you've
> both thought about this more carefully than I have, and I respect your
> judgement.  You wouldn't suggest applying a patch at this stage of the
> game unless you were sure it's an improvement.  
> 

The patch touch a part of FreeTDS that is quite "sensible" however I
don't like to have a "fork" on network that are just 10 line
different... Steve implemented one of our idea for this part (use
setting from environment) so it would be fine if we can find a common
solution. 

> I'll apply it and post 0.64rc3.  If there's something more that needs
> doing, tell me.  
> 

There are some points to resolve. Why do patch set client_charset and
also char_set (now server_charset)? IMO should set just client_charset
and let other code find better server_charset that match client one.
Another question is: why have we the server charset in locales.conf??
This charset should be a charset detected by FreeTDS so FreeTDS should
be able to detect proper client charset. Perhaps is useful if we want to
specify the server charset when server is not able to handle client
translated correctly (this happen for instance using utf8 for older
server). However someone could complain that currently there is no
translation for Sybase and mssql do not care about server charset.

> I'll look again at the patch, of course, but let me restate my
> understanding of your intent:
> 
> 1.  Absent an override, use nl_langinfo(3) to determine the client
> charset. 
> 2.  The environment settings are overridden by 'client charset' in
> freetds.conf. 

Agree, locales.conf and "client charset" in freetds.conf are mainly for
overriding 

> 3.  nl_langinfo() is not available and 'client charset' is absent,
> locales.conf will be used to infer a client character set.  

Agree, locales.conf should replace nl_langinfo. Note however that it can
happen that nl_langinfo is present but is not valid ("C C C" or
similar). In case we want to override valid nl_langinfo or detected
server charset we can override in freetds.conf.

> 4.  Charset information is used both by iconv and in the TDS 5.0 login.  
> 

Yes, and I would add that server_charset is used only for Sybase (or
former mssql versions) and only as an override for some server settings.

> > I'll talk to Adam Conrad and see if we can get this fixed up yet for
> > Dapper.
> 
> As you see fit.  I can see advantages both ways.  The situation AIUI is
> that the Sybase server is initially asked to use a character set it
> doesn't suppport.  It feeds that back to the client in a message, and
> FreeTDS responds accordingly.  The only problem is that it can't be
> overridden, and causes log messages to accumulate on the server.  
> 

I would be perfect if FreeTDS detect this message and use proper iconv.
But let this for a future release...

> I would find it very helpful if you'd let us know what patch, if any, you
> include in your releases.  Certainly it would have shortened this thread. 
> :-)
> 

Cfr. "0.64rc2 Debian prerelease packages available", 31 March.

bye
  freddy77