Re: Removing support for < 7.4 servers

On Fri, Mar 7, 2014 at 10:25 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Yeah, around that I time I guess. I believe the packagers would prefer for
> the driver release some weeks before the server release, so that they have
> time to package it and release together with the server.

OK, I have created a fork on github here
(https://github.com/michaelpq/psqlodbc) with all the cleanup related
code in a dedicated branch called cleanup-9.4. I might rebase this
branch based on latest HEAD of odbc from time to time to avoid any
conflicts when applying the cleanup patches. 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.
- Removal of the ODBCVER blocks.
- Update of documentation, removing referencies to old server versions.
- 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.

This makes me think that we should add some regression tests for
SQLGetTypeInfo, SQLColumns, SQLSpecialColumns & friends. Thoughts?

I noticed as well the following things in the code that may need some
more thinking:
- Reorganization of the code organized by versions (I am thinking that
grouping those APIs makes sense if we drop the ODBCVER ifdef blocks
and protocols older than 7.4). Following files are impacted:
odbcapi*.c info*.c, pgapi*.c
- Some code has been added for support of SQL_INTERVAL in commit
6e45dcb, but it is disabled with flag PG_INTERVAL_AS_SQL_INTERVAL.
Should we do something about that? And what are the applications that
faced problems with that?
- I am not sure that odbc.sql and odbc-drop.sql are of any use. Should
we remove them?
- Is inouealc.c in the code tree for conveniency?
Regards,
--
Michael