FreeTDS Development Group

[Stephen Marshall <smarshall AT kayak.com>]

Overall, I agree with comments from both Frediano and James about honoring
the settings in the configuration file, unless they are specifically
overridden by calls to ct_con_props.  However, I'm concerned about the
magnitude of changes to accomplish this.  Connection information can come
from a lot of directions, including:
* ct_con_props calls
* lookup from global part of freetds.conf file
* lookup by server name from freetds.conf file
* environment variables
* heuristic rules, e.g. special case when server name matches the pattern
"<host>:<port>".

In my opinion, the priority of these information sources should be, from
lowest to highest priority:
1. Hard coded defaults
2. Environment variables
3. Global config values from freetds.conf
4. Server-specific values from freetds.conf
5. Settings specifically made by calls to ct_con_props

The code should be reworked to set connection parameters in priority order,
with each level in the hierarchy overriding settings in the previous level.
The special case heuristics should all be removed, if possible.

As far as I can tell, such a change would require the connection logic to
be completely refactored.  This is no small task, and would require a lot
of testing to weed out unintended side effects. Is there someone in the
FreeTDS community with an appetite for this level of change to the
conniption subsystem?




On Fri, Jan 10, 2014 at 6:39 PM, James K. Lowden <jklowden AT freetds.org>wrote:

> On Fri, 10 Jan 2014 00:03:42 +0000
> Frediano Ziglio <freddy77 AT gmail.com> wrote:
>
> > - should configuration NEVER be read if CS_SERVERADDR is used? Looking
> > at libTDS code (tds_read_config_info) seems that an attempt to read
> > configuration is always done, even for server:port syntax. However
> > setting server_name to "" should cause only global section to be
> > parsed.
>
> ISTM the global section of freetds.conf should apply regardless.
>
> Global is global.  If you don't want a global setting, don't set it.
> If you want to override it, use an environment variable.
>
> Another way to think about it: just because we don't need to use
> freetds.conf to resolve a name for a particular host when an address is
> provided doesn't imply that non-host (global) settings are invalid.
>
> The configuration establishment code was never my favorite.  Too much
> logic for very little data.  It could use some TLC from someone with a
> preference for table-driven design.
>
> HTH.
>
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>