Re: Removing support for < 7.4 servers

On Wed, Mar 12, 2014 at 5:50 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 03/12/2014 10:10 AM, Michael Paquier wrote:
>> For the time being I have done the following:
>> - Removal of protocol older than 7.4 (including ksqo, schema_support).
>> Thanks Heikki for the patch. It would have been actually hard to
>> remove the ksqo things, I don't know much the history of Postgres <
>> 7.4.
>
>
> Now that we don't need the Protocol setting for the actual protocol version,
> I think we should invent a new setting for the "rollback" behavior. It's
> currently stored as a prefix of the protocol, which IMHO never made much
> sense, but now even less. Accept it in the Protocol setting for
> backwards-compatibility, but document the new field as the primary setting
> and use that in the examples and GUI.
I see, that's the (0|1|2) part of the Protocol string. What about
RollbackOnError as name for the new parameter?

>> - Changed PRECISION field to use COLUMN_SIZE when getting the
>> information of a type (patch attached as it is simple). I have let
>> COLUMN_PRECISION as it is as COLUMNS_COLUMN_SIZE is kind of strange,
>> only changed the type name reported.
>
>
> I didn't quite understand this, but in general, I think we should
> consistently use the new attribute names.
The order of the fields for SQLTables, SQLColumns, etc. is decided by
some enums in catfunc.h. PRECISION/COLUMN_SIZE is referenced there as
COLUMNS_PRECISION. What I have done in my patch was changing the
column name returned to the caller of PGAPI_GetTypeInfo, but not the
internal reference called COLUMNS_PRECISION.

> Also note that the driver manager actually does some mapping of deprecated
> ODBC function calls to the new functions, so that the driver only needs to
> provide the ODBC 3.X functions. For example, if the driver doesn't provide
> the deprecated SQLGetStmtAttr function, and the application calls it, the
> driver manager will call SQLGetStmtOption instead (or just handle the call
> internally without calling the driver, depending on the attribute). So once
> we drop support for compiling the driver in ODBC 2.X mode, we could
> completely drop many of the interface functions. before we actually do that,
> though, it would be good to have regression test coverage of the deprecated
> functions with different attributes, to make sure they get mapped correctly
> and still work if used in an application.
I found the following list of deprecated functions:
http://msdn.microsoft.com/en-us/library/ms716309%28v=vs.85%29.aspx
By having a quick look at the code, this results in removing
odbcapi25w.c. Am I missing some of them?

>> This makes me think that we should add some regression tests for
>> SQLGetTypeInfo, SQLColumns, SQLSpecialColumns & friends. Thoughts?
>
>
> Yeah, absolutely. Would be good to run a code coverage report (e.g lcov) to
> see which SQL interface functions are not currently covered by the
> regression tests.
I imagine that it makes sense to have those tests in current HEAD as well...

So, following this email, the next real step is providing additional
regression tests just to be sure that we are breaking nothing when
dropping support for the older protocols...
--
Michael