Re: Compiling Against FreeTDS 0.95 w/7.3 TDSVER Features Possible?

Il 23/Nov/2015 07:19, "LacaK" <[email protected]> ha scritto:
>
>
>>
>> I pushed some changes to master to integrate dbanydatecrack. This
>> function use new DBDATEREC2 type which change milliseconds to
>> nanoseconds in the DBDATEREC structure and accepts an additional type
>> parameter (which can be returned by dbcoltype) for the type.
>> So you can use dbdata+dbcoltype+dbanydatecrack to parse any date/time
>> type (even future BIGTIME or whatever). The idea is to backport these
>> changes in 0.95 too.
>>
>> Could you try if works for you? I extended a test and is actually
working.
>
>
> Only formal note:
> for me better sounds "dbdatecrack2()" as "dbanydatecrack()"
> (or "tdsdbdatecrack()" as there is already "tdsdbopen()" versus
"dbopen()" ?
>  or "dbdatetimecrack()" ?)
>

It's quite a personal choice. The rationale behind tdsdbopen was different.
Was supposed to be an ABI not called directly but to be possible to have
dbopen as ABI (so to keep old one) and a new dbopen API which call a new
ABI (tdsdbopen was choosed).

The rationale against dbanydatecrack is that:
- is a new API and ABI;
- I want to keep dblib db prefix;
- dbdatecrack handle only DB DATE TIME so calling new one dbdatetimecrack
is confusing;
- can be thought as an extension to dbdatecrack, yes, so the name
dbdatecrack2 may sound reasonable also thinking about DBDATEREC2... on the
other way it state more precisely that handle all date type instead of just
one.

So... All that reasonings exclude either tdsdbdatecrack and
dbdatetimecrack. About the choice between dbdatecrack2 and dbanydatecrack I
think we are one against one. I prefer dbanydatecrack.

Frediano