[freetds] idea: eliminate port/instance
robert at robert-gonzalez.com
Sat Apr 4 16:36:07 EDT 2009
Personally, for what I use FreeTDS for, I would have no object to what you
want to do. Making changes to current conf files would require minimal work
at worst, so I am OK with it.
+1 from me for making the changes if it makes it easier for you to
develop/maintain and easier for users to use.
On Sat, Apr 4, 2009 at 1:29 PM, James K. Lowden <jklowden at freetds.org>wrote:
> 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
> 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().
> 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.
> Thoughts? Patches? Anyone out there with a freetds.conf that would take
> more than a few minutes to update?
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
More information about the FreeTDS