[freetds] idea: eliminate port/instance
freddy77 at gmail.com
Sun Apr 5 10:00:34 EDT 2009
2009/4/4 James K. Lowden <jklowden at freetds.org>:
> I propose to eliminate "port" and "instance" from freetds.conf. I'd like
> feedback on the idea.
> In freetds.conf, one can specify:
> Port and instance are mutually exclusive. People get confused; they
> specify both, and then don't know (because we don't say) that port
> overrides instance. You could think of that as a failure ... of
> documentation or of design.
> My first thought was to eliminate "instance", and use port as follows:
> 1. If port is numeric, it's a port.
> 2. If port is non-numeric, try looking up the port with getservbyname(3).
> 3. If getservbyname(3) fails, look up the port using the UDP instance
I personally don't like this way cause you can't specify a named
instance if this instance correspond to a service entry.
> We could instead print loudly to stderr when both port and instance are
> found in the same section. But that won't help when Apache is involved
> and/or standard error is closed.
> But overloading "port" to sometimes mean an instance name could also sow
> Simplest is to eliminate port *and* instance, and denote it this way:
> host = servername:port
> host = servername:instance
> and apply the above three rules to whatever is right of the colon.
> That mimics URL notation and config.c::parse_server_name_for_port().
We have to consider that we are breaking compatibility. Personally I
would suggest to use another way to specify that user is using an old
configuration and remove support after some release. Users don't like
that early configuration stop working. I never liked that much
server:port syntax but perhaps it would be better to use server:port
and server\instance like odbc (and also CVS HEAD syntax if I
> I would stop supporting port & instance immediately. The release notes
> would alert users to the change. I don't want to support both because the
> whole problem is confusion stemming from needless complexity.
> At the same time, I would change the freetds.conf parser to emit messages
> on standard error when it finds problems in the file. (Currently
> misconfigurations and unknown options are silently ignored.) That will
> help people using, say, tsql to know their setup has a problem.
IMHO libraries should not output to stderr if not required explicitly to do so.
> Thoughts? Patches? Anyone out there with a freetds.conf that would take
> more than a few minutes to update?
Perhaps it would be useful to always return error if port and instance
are both specified.
More information about the FreeTDS