Обсуждение: Removing support for < 7.4 servers
Hi, I've been browsing the code to figure out how we could use protocol-level cursors, instead of DECLARE/FETCH, to make the default behavior of the driver nicer. However, all the different ways a query can be prepared and executed is making my head explode. The driver supports many completely obsoleted ways to do things, for the sake of supporting 7.3 era servers which didn't support the extended query protocol. There is even some code to support 6.2-era servers. I'd like to rip out all the support for pre-7.4 servers, including protocol version 2, to simplify the code. Any objections? If someone is running a really old server version, I think it's fair to insist that they also use a somewhat old version of the driver. (the only thing anyone should be doing with 7.3 servers today is pg_dump, to be honest) I pushed a patch to github to do that, to see what the effect is to the code: https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b73360a2c515a2fec79 $ git diff --stat master..require74 columninfo.c | 51 ++- columninfo.h | 2 +- connection.c | 766 +++++++++---------------------------- connection.h | 60 +-- convert.c | 235 ++---------- descriptor.c | 10 - dlg_specific.c | 82 ++-- dlg_specific.h | 8 +- dlg_wingui.c | 24 -- execute.c | 54 +-- info.c | 1148 +++++++++++++++++--------------------------------------- info30.c | 47 +-- misc.c | 4 +- multibyte.c | 33 +- odbcapi.c | 6 +- odbcapiw.c | 3 +- options.c | 5 - parse.c | 90 ++--- pgtypes.c | 43 +-- psqlodbc.h | 9 - psqlodbc.rc | 22 -- qresult.c | 113 ++---- resource.h | 5 - results.c | 167 ++++----- socket.c | 34 +- socket.h | 3 - statement.c | 39 +- statement.h | 6 - 28 files changed, 784 insertions(+), 2285 deletions(-) That's just the beginning though. I think we can get rid of much of the "premature execution" stuff, replacing it with the v3 protocol-level Describe functionality. The driver already uses that in many cases, but not all. That requires some more investigation and thorough testing of all the corner cases, though. Timingwise, I'm thinking we would do this in the first 9.4 version of the driver. The server guys will put out the 9.3 release in the next couple of weeks, so we should put out a stable 9.3 version of the ODBC driver very soon. But after that, we can do more drastic changes again. - Heikki
On 08/20/2013 03:53 AM, Heikki Linnakangas wrote: > Hi, > > ... > I'd like to rip out all the support for pre-7.4 servers, including > protocol version 2, to simplify the code. Any objections? If someone > is running a really old server version, I think it's fair to insist > that they also use a somewhat old version of the driver. (the only > thing anyone should be doing with 7.3 servers today is pg_dump, to be > honest) Speaking generally as a user... It seems like this might be a good opportunity to establish an overall support/EOL policy for the drivers. Anyone running 7.4 has been on their own for years anyway and shouldn't expect driver authors to spend valuable development resources supporting those outdated systems. I would not personally object to a driver EOL/support policy that tracks alongside the EOL/support schedule of PostgreSQL itself. If support for anything pre-8.4 is impeding you, drop it. Cheers, Steve
On Tue, Aug 20, 2013 at 7:53 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > I've been browsing the code to figure out how we could use protocol-level > cursors, instead of DECLARE/FETCH, to make the default behavior of the > driver nicer. However, all the different ways a query can be prepared and > executed is making my head explode. The driver supports many completely > obsoleted ways to do things, for the sake of supporting 7.3 era servers > which didn't support the extended query protocol. There is even some code to > support 6.2-era servers. > > I'd like to rip out all the support for pre-7.4 servers, including protocol > version 2, to simplify the code. Any objections? If someone is running a > really old server version, I think it's fair to insist that they also use a > somewhat old version of the driver. (the only thing anyone should be doing > with 7.3 servers today is pg_dump, to be honest) > > I pushed a patch to github to do that, to see what the effect is to the > code: > https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b73360a2c515a2fec79 +1. It looks like a good plan to refresh this code tree by removing old protocols, and just by seeing the first patch you sent, code is simplified in many places. > That's just the beginning though. I think we can get rid of much of the > "premature execution" stuff, replacing it with the v3 protocol-level > Describe functionality. The driver already uses that in many cases, but not > all. That requires some more investigation and thorough testing of all the > corner cases, though. Regression tests and precise documentation would be a nice addition as well when doing this implementation. > Timingwise, I'm thinking we would do this in the first 9.4 version of the > driver. The server guys will put out the 9.3 release in the next couple of > weeks, so we should put out a stable 9.3 version of the ODBC driver very > soon. But after that, we can do more drastic changes again. Agreed. -- Michael
(2013/08/20 19:53), Heikki Linnakangas wrote: > Hi, > > I've been browsing the code to figure out how we could use > protocol-level cursors, instead of DECLARE/FETCH, to make the default > behavior of the driver nicer. Protocol-level cursors don't support SCROLLABLE or HOLDABLE option unfortunately. > However, all the different ways a query > can be prepared and executed is making my head explode. The driver > supports many completely obsoleted ways to do things, for the sake of > supporting 7.3 era servers which didn't support the extended query > protocol. There is even some code to support 6.2-era servers. > > I'd like to rip out all the support for pre-7.4 servers, including > protocol version 2, to simplify the code. Any objections? If someone is > running a really old server version, I think it's fair to insist that > they also use a somewhat old version of the driver. (the only thing > anyone should be doing with 7.3 servers today is pg_dump, to be honest) Agreed. > I pushed a patch to github to do that, to see what the effect is to the > code: > https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b73360a2c515a2fec79 > > > $ git diff --stat master..require74 > columninfo.c | 51 ++- > columninfo.h | 2 +- > connection.c | 766 +++++++++---------------------------- > connection.h | 60 +-- > convert.c | 235 ++---------- > descriptor.c | 10 - > dlg_specific.c | 82 ++-- > dlg_specific.h | 8 +- > dlg_wingui.c | 24 -- > execute.c | 54 +-- > info.c | 1148 > +++++++++++++++++--------------------------------------- > info30.c | 47 +-- > misc.c | 4 +- > multibyte.c | 33 +- > odbcapi.c | 6 +- > odbcapiw.c | 3 +- > options.c | 5 - > parse.c | 90 ++--- > pgtypes.c | 43 +-- > psqlodbc.h | 9 - > psqlodbc.rc | 22 -- > qresult.c | 113 ++---- > resource.h | 5 - > results.c | 167 ++++----- > socket.c | 34 +- > socket.h | 3 - > statement.c | 39 +- > statement.h | 6 - > 28 files changed, 784 insertions(+), 2285 deletions(-) > > That's just the beginning though. I think we can get rid of much of the > "premature execution" stuff, replacing it with the v3 protocol-level > Describe functionality. "Premature execution" should be removed completely when we remove support for < 7.4 servers. regards, Hiroshi Inoue
On Tue, Aug 20, 2013 at 7:53 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > I'd like to rip out all the support for pre-7.4 servers, including protocol > version 2, to simplify the code. Any objections? If someone is running a > really old server version, I think it's fair to insist that they also use a > somewhat old version of the driver. (the only thing anyone should be doing > with 7.3 servers today is pg_dump, to be honest) > > I pushed a patch to github to do that, to see what the effect is to the > code: > https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b73360a2c515a2fec79 Heikki, do you plan to rework on that soon or do you mind if I look at it? I imagine that such cleanup is still welcome for the code. Regards, -- Michael
On 03/07/2014 08:41 AM, Michael Paquier wrote: > On Tue, Aug 20, 2013 at 7:53 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> I'd like to rip out all the support for pre-7.4 servers, including protocol >> version 2, to simplify the code. Any objections? If someone is running a >> really old server version, I think it's fair to insist that they also use a >> somewhat old version of the driver. (the only thing anyone should be doing >> with 7.3 servers today is pg_dump, to be honest) >> >> I pushed a patch to github to do that, to see what the effect is to the >> code: >> https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b73360a2c515a2fec79 > Heikki, do you plan to rework on that soon or do you mind if I look at > it? I imagine that such cleanup is still welcome for the code. Yes, it's still very much welcome. Feel free. In addition to the protocol stuff, I think we can safely assume we're building with ODBCVER 0x351, and remove all the #ifdefs around that. I think we could also change the column names discussed here: http://www.postgresql.org/message-id/5315E622.2010904@ntlworld.com. Anything else we'd like to clean up? Perhaps we should create a wiki page for this in wiki.postgresql.org. It would be good to do such big changes as part of the next major release, 09.04.xxxx. But we need to start doing them earlier, and continue to do bug fixes for the 09.03.xxxx series at the same time. Historically, we've only maintained one branch of psqlodbc, the latest one. I don't think we want to change that, so we need to be fairly careful to not do any big behavioral changes to existing applications. Otherwise an application could get stuck on an older release. Even with that constraint, there's a lot of old cruft that we could safely remove and clean up. I'd suggest that you do the changes on a fork in github and keep the mailing list posted on how it's going, and we merge that into the main psqlodbc repository when it's time for the 09.04.xxxx release. If you create new test cases, those should work with the current codebase as well, so we can merge those into the master branch earlier. So please post those separately to the mailing list as you go. - Heikki
On Fri, Mar 7, 2014 at 5:12 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > It would be good to do such big changes as part of the next major release, > 09.04.xxxx. But we need to start doing them earlier, and continue to do bug > fixes for the 09.03.xxxx series at the same time. Historically, we've only > maintained one branch of psqlodbc, the latest one. I don't think we want to > change that, so we need to be fairly careful to not do any big behavioral > changes to existing applications. Otherwise an application could get stuck > on an older release. Even with that constraint, there's a lot of old cruft > that we could safely remove and clean up. It would be nice IMO if odbc follows a branching model similar to jdbc or Postgres itself with stable branches dedicated to each major release. i imagine that as long as the clean up is not really done, such a development model is complicated because it would make development of bug fixes on back-branches more complicated though... > I'd suggest that you do the changes on a fork in github and keep the mailing > list posted on how it's going, and we merge that into the main psqlodbc > repository when it's time for the 09.04.xxxx release. Yep, no problem. Hm... I understand that this is hard to estimate, but I suppose that a potential target for a 09.04.X release would be once Postgres 9.4.0 is out. Thoughts? > If you create new test cases, those should work with the current codebase as > well, so we can merge those into the master branch earlier. So please post > those separately to the mailing list as you go. Sure. -- Michael
On 03/07/2014 02:50 PM, Michael Paquier wrote: > On Fri, Mar 7, 2014 at 5:12 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> It would be good to do such big changes as part of the next major release, >> 09.04.xxxx. But we need to start doing them earlier, and continue to do bug >> fixes for the 09.03.xxxx series at the same time. Historically, we've only >> maintained one branch of psqlodbc, the latest one. I don't think we want to >> change that, so we need to be fairly careful to not do any big behavioral >> changes to existing applications. Otherwise an application could get stuck >> on an older release. Even with that constraint, there's a lot of old cruft >> that we could safely remove and clean up. > It would be nice IMO if odbc follows a branching model similar to jdbc > or Postgres itself with stable branches dedicated to each major > release. i imagine that as long as the clean up is not really done, > such a development model is complicated because it would make > development of bug fixes on back-branches more complicated though... Well, as long as there are no big behavioral changes in the driver, there's not much point maintaining back-branches. Users might as well just grab the latest driver. >> I'd suggest that you do the changes on a fork in github and keep the mailing >> list posted on how it's going, and we merge that into the main psqlodbc >> repository when it's time for the 09.04.xxxx release. > Yep, no problem. Hm... I understand that this is hard to estimate, but > I suppose that a potential target for a 09.04.X release would be once > Postgres 9.4.0 is out. Thoughts? 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. psqlodbc has always been pretty relaxed about the schedule, and has often lagged behind the server major version by months. There hasn't really been much difference between a major vs. minor version bump in psqlodbc. - Heikki
It's perhaps worth noting that in the recent past (and possibly in the current release -- I haven't checked) the ANSI driveron windows was built as ODBC version 3 instead of 3.5. I raised this issue when I discovered it (see the post titled"UUID returned as SQL_VARCHAR instead of SQL_GUID, contains no data" from 10/10/2012) but I never got a response andto my knowledge it's not been changed. I don't know if there was ultimately some reason why that build needed to use the older ODBC revision, or if it's just somethingthat was overlooked. - Dan -----Original Message----- From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Heikki Linnakangas Sent: Friday, March 07, 2014 12:12 AM To: Michael Paquier Cc: pgsql-odbc@postgresql.org Subject: Re: [ODBC] Removing support for < 7.4 servers On 03/07/2014 08:41 AM, Michael Paquier wrote: > On Tue, Aug 20, 2013 at 7:53 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> I'd like to rip out all the support for pre-7.4 servers, including >> protocol version 2, to simplify the code. Any objections? If someone >> is running a really old server version, I think it's fair to insist >> that they also use a somewhat old version of the driver. (the only >> thing anyone should be doing with 7.3 servers today is pg_dump, to be >> honest) >> >> I pushed a patch to github to do that, to see what the effect is to >> the >> code: >> https://github.com/hlinnaka/psqlodbc/commit/d5cbe6e62a72d87200217b733 >> 60a2c515a2fec79 > Heikki, do you plan to rework on that soon or do you mind if I look at > it? I imagine that such cleanup is still welcome for the code. Yes, it's still very much welcome. Feel free. In addition to the protocol stuff, I think we can safely assume we're building with ODBCVER 0x351, and remove all the #ifdefsaround that. I think we could also change the column names discussed here: http://www.postgresql.org/message-id/5315E622.2010904@ntlworld.com. Anything else we'd like to clean up? Perhaps we should create a wiki page for this in wiki.postgresql.org. It would be good to do such big changes as part of the next major release, 09.04.xxxx. But we need to start doing them earlier,and continue to do bug fixes for the 09.03.xxxx series at the same time. Historically, we've only maintained one branch of psqlodbc, the latest one. I don't think we want to change that, so we needto be fairly careful to not do any big behavioral changes to existing applications. Otherwise an application could get stuck on an older release. Even with that constraint, there's a lot of old cruft thatwe could safely remove and clean up. I'd suggest that you do the changes on a fork in github and keep the mailing list posted on how it's going, and we mergethat into the main psqlodbc repository when it's time for the 09.04.xxxx release. If you create new test cases, those should work with the current codebase as well, so we can merge those into the masterbranch earlier. So please post those separately to the mailing list as you go. - Heikki -- Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-odbc
On Tue, Mar 11, 2014 at 1:36 AM, Daniel Homerick
<daniel.homerick@2d3sensing.com> wrote:
> It's perhaps worth noting that in the recent past (and possibly in the current release -- I haven't checked) the ANSI
driveron windows was built as ODBC version 3 instead of 3.5. I raised this issue when I discovered it (see the post
titled"UUID returned as SQL_VARCHAR instead of SQL_GUID, contains no data" from 10/10/2012) but I never got a response
andto my knowledge it's not been changed.
>
> I don't know if there was ultimately some reason why that build needed to use the older ODBC revision, or if it's
justsomething that was overlooked.
Interestingly, I noticed this piece of code in connection.c, which
might be a consequence of that:
rv->driver_version = ODBCVER;
#ifdef WIN32
if (VER_PLATFORM_WIN32_WINDOWS == platformId && rv->driver_version > 0x0300)
rv->driver_version = 0x0300;
#endif /* WIN32 */
The driver informs that the version it uses is 0x0300. It has been
introduced by commit 08b2a1c.
Regards,
--
Michael
On Fri, Mar 7, 2014 at 10:25 PM, Heikki Linnakangas <hlinnakangas@vmware.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
Вложения
On 03/12/2014 10:10 AM, Michael Paquier wrote: > On Fri, Mar 7, 2014 at 10:25 PM, Heikki Linnakangas > <hlinnakangas@vmware.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. Ahh, that's the way I like my patches: 49 files changed, 273 insertions(+), 2571 deletions(-) :-) > I might rebase this > branch based on latest HEAD of odbc from time to time to avoid any > conflicts when applying the cleanup patches. Yeah, please do. I find it easier to work with branches that are rebased over current master, rather than merged. > 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. > - 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. 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. > 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 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 Agreed. > - 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? No idea. > - I am not sure that odbc.sql and odbc-drop.sql are of any use. Should > we remove them? Probably. The script still works, but I'm not sure how useful it is. > - Is inouealc.c in the code tree for conveniency? I believe the purpose is to find memory leaks. I'm not sure how useful that is nowadays; it's probably easier to just run the regression tests under valgrind. - Heikki
On 03/12/2014 10:10 AM, Michael Paquier wrote: > On Fri, Mar 7, 2014 at 10:25 PM, Heikki Linnakangas > <hlinnakangas@vmware.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: BTW, please keep brief a list of the changes you've made, especially for any backwards-incompatible changes. That'll come handy when it's time to write the release notes. - Heikki
On Wed, Mar 12, 2014 at 5:51 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 03/12/2014 10:10 AM, Michael Paquier wrote: > BTW, please keep brief a list of the changes you've made, especially for any > backwards-incompatible changes. That'll come handy when it's time to write > the release notes. Sure, I'll add a page on the postgres wiki for that. -- Michael
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
On Wed, Mar 12, 2014 at 8:17 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Mar 12, 2014 at 5:51 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> On 03/12/2014 10:10 AM, Michael Paquier wrote: >> BTW, please keep brief a list of the changes you've made, especially for any >> backwards-incompatible changes. That'll come handy when it's time to write >> the release notes. > Sure, I'll add a page on the postgres wiki for that. And here is the wiki page: https://wiki.postgresql.org/wiki/ODBC_Updates_with94 Feel free to ping me if you think that modifications are required, or to modify the page directly... Regards, -- Michael
On Thu, Mar 13, 2014 at 11:36 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > And here is the wiki page: > https://wiki.postgresql.org/wiki/ODBC_Updates_with94 > Feel free to ping me if you think that modifications are required, or > to modify the page directly... Just to keep everybody updated, I have done some progress for that: - Cleanup of the #ifdef ODBCVER blocks - Removal of all references to ~7.4 servers in documentation - Removal of code paths for ~7.4 servers (ksqo, etc.) - Renaming of column PRECISION to COLUMN_SIZE in pgtypes.c - Reorganization and grouping of info*.c, odbcapi*.c, pgapi*.c All those things are organized in different commits in the fork of odbc I am keeping on github to facilitate future merge, and pass all the regression tests including the latest ones committed. The following things are still unclear to me: - What to do with PG_INTERVAL_AS_SQL_INTERNAL? It is said that applications using that got broken. - odbc.sql, odbc-drop.sql and inouealc.c do not seem mandatory in the code tree. About the regression tests, all the things I got in mind are done, committed thanks to Heikki. Only remains the support of regression tests on Windows. Regards, -- Michael
On Tue, Apr 1, 2014 at 8:00 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > Just to keep everybody updated, I have done some progress for that: > - Cleanup of the #ifdef ODBCVER blocks > - Removal of all references to ~7.4 servers in documentation > - Removal of code paths for ~7.4 servers (ksqo, etc.) > - Renaming of column PRECISION to COLUMN_SIZE in pgtypes.c > - Reorganization and grouping of info*.c, odbcapi*.c, pgapi*.c > All those things are organized in different commits in the fork of > odbc I am keeping on github to facilitate future merge, and pass all > the regression tests including the latest ones committed. This work has been rebased on latest master commit (9e71e4d): https://github.com/michaelpq/psqlodbc/tree/cleanup-94 -- Michael
On 06/09/2014 03:59 AM, Michael Paquier wrote: > On Tue, Apr 1, 2014 at 8:00 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> Just to keep everybody updated, I have done some progress for that: >> - Cleanup of the #ifdef ODBCVER blocks >> - Removal of all references to ~7.4 servers in documentation >> - Removal of code paths for ~7.4 servers (ksqo, etc.) >> - Renaming of column PRECISION to COLUMN_SIZE in pgtypes.c >> - Reorganization and grouping of info*.c, odbcapi*.c, pgapi*.c >> All those things are organized in different commits in the fork of >> odbc I am keeping on github to facilitate future merge, and pass all >> the regression tests including the latest ones committed. > This work has been rebased on latest master commit (9e71e4d): > https://github.com/michaelpq/psqlodbc/tree/cleanup-94 Great, thanks for working on this! - Heikki
On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
-- This work has been rebased on latest master commit (9e71e4d):
https://github.com/michaelpq/psqlodbc/tree/cleanup-94
Ping. Code rebased on 58ca764.
Michael
On Mon, Jun 23, 2014 at 2:41 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier <michael.paquier@gmail.com> > wrote: >> This work has been rebased on latest master commit (9e71e4d): >> https://github.com/michaelpq/psqlodbc/tree/cleanup-94 > Ping. Code rebased on 58ca764. Ping. Code rebased on 8d0e832. -- Michael
On Sun, Aug 10, 2014 at 10:18 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
-- On Mon, Jun 23, 2014 at 2:41 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier <michael.paquier@gmail.com>
> wrote:
>> This work has been rebased on latest master commit (9e71e4d):
>> https://github.com/michaelpq/psqlodbc/tree/cleanup-94
Ping. Code rebase on c685835.
Michael
On 10/07/2014 10:29 AM, Michael Paquier wrote: > On Sun, Aug 10, 2014 at 10:18 PM, Michael Paquier <michael.paquier@gmail.com >> wrote: > >> On Mon, Jun 23, 2014 at 2:41 PM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >>> On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier < >> michael.paquier@gmail.com> >>> wrote: >>>> This work has been rebased on latest master commit (9e71e4d): >>>> https://github.com/michaelpq/psqlodbc/tree/cleanup-94 >> > Ping. Code rebase on c685835. Ok, I think it's time to go ahead with this. Committed the first patch in that series, removing support for old protocol versions. Will review the rest now. I don't have the GUI tools to modify the configuration dialogs, so I just removed the stuff for KSQO and choosing the protocol. That seems to be enough to make it compile, but there's now just gaps in the dialog where those options used to be. Will need some re-organizing to make it pretty again. - Heikki
On Thu, Oct 30, 2014 at 1:41 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 10/07/2014 10:29 AM, Michael Paquier wrote: >> >> On Sun, Aug 10, 2014 at 10:18 PM, Michael Paquier >> <michael.paquier@gmail.com >>> >>> wrote: >> >> >>> On Mon, Jun 23, 2014 at 2:41 PM, Michael Paquier >>> <michael.paquier@gmail.com> wrote: >>>> >>>> On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier < >>> >>> michael.paquier@gmail.com> >>>> >>>> wrote: >>>>> >>>>> This work has been rebased on latest master commit (9e71e4d): >>>>> https://github.com/michaelpq/psqlodbc/tree/cleanup-94 >>> >>> >> Ping. Code rebase on c685835. > > > Ok, I think it's time to go ahead with this. Committed the first patch in > that series, removing support for old protocol versions. Will review the > rest now. Thanks for looking at that. Why not marking as well the next release as 09.04.XX? -- Michael