Re: ignore --tdsver
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 08 Sep 2011 12:22:14 -0500 "Craig A. Berry" <[email protected]> wrote: > 5.0 may not be a sensible default in this day and age. But I'm not > sure there is a different one that makes sense either. I'd like to riff on that a bit. The right default might be "auto", which is currently supported in, er, CVS HEAD. The recent discussion of dbsetversion() is illustrative. The documentation says if you don't call it, you get TDS 4.2. That makes sense: recompile old code, link to new library, get same behavior. To get new behavior, call the (previously nonexistent) function. But it also doesn't make sense. Write brand new code, and to get modern behavior you have call the (otherwise meaningless) function. ODBC has been stuck with this for a decade, cf. SQL_ATTR_ODBC_VERSION. You actually call the API to change the API. Larry Wall mentioned a similar artifact once in writing about Perl 6. He remembered IIRC a setting in VMS mumble something like SET EXTENDED ON to make it DTRT. He observed that thereafter *every* script needed that boilerplate in its preamble. One gets the sense Larry is not a fan of boilerplate or, for that matter, preambles. That's the world of binary interfaces and closed source. Free software lets you set the "default defaults" with ./configure. Because you control the source, you can set the default at compile time, which is why the inoperability of dbset[l]version went unremarked-on for years. If we were to remove --with-tdsver (which we won't) we'd remove only the ability to set the compiled-in default. If you don't use that configure option, you get 5.0. It has to be *something*, even if it's an invalid value that forces you to use one of the runtime or programatic methods to set it to something valid. Which brings us back to: what should it be? Which makes me ask: what's a configure file for, anyway? freetds.conf associates a hostname, port, and TDS version with a local name. Hostname is converted to an IP address by DNS or similar. Port is discoverable on Microsoft servers using 1434. And TDS version can be found by starting high and working down. Old servers reject logins using newer versions of the protocol; from their perspective the new version is a protocol violation. By trying successively lower version, a client can discover the highest one supported by a server. What that means to me is that FreeTDS in its next release should normally be run without a configuration file or environment variables. The default-default TDS version should be 0, which tells the login function to keep trying TDS flavors as long as something accepts the tcp/ip connection. That said, there is miniscule overhead in retrying logins, and it is unnecessary if you know which TDS version the server wants, and for some applications a few hundred milliseconds' delay to log in matters. The spirit of the project demands that users be able to nail things down, even to the point of setting the compiled-in default behavior. End of Riff. Thanks for listening. --jkl