Thread: Next development steps?
Hello,
I study the driver and there are lot of code which doesn't work since
libpq support. (e.g.) There is support for updatable cursor which doesn't
work (if I'm right) because it's using backend_tuples which isn't
supported.
It seems no other (except swamped Dave and Anoop) is supporting ODBC
driver. I propose these steps:
1) clean the code (and UI) with drop all non-trivial features
- these features make the code unreadable and complicated with
no proper behaviour right now
- there is no error report for them since libpq support
(exclude [#1000413] Optimistic lock cannot be used with updateable
cursors - I think updateable cursor doesn't work at all)
2) create better transaction support (see Marco Ristola post)
- http://archives.postgresql.org/pgsql-odbc/2005-03/msg00128.php
- http://archives.postgresql.org/pgsql-odbc/2005-03/msg00116.php
3) improve libpq support to use PQprepare, bind parameters
4) full support for only_forward read-only cursor
5) create small steps in support dropped things
and so on ...
Can we create a new development branch at least?
What do you think about it?
Luf
Hi Ludek. > It seems no other (except swamped Dave and Anoop) is supporting ODBC > driver. I propose these steps: > Can we create a new development branch at least? > > What do you think about it? You certain meaning right. However, Doing one DEBUG work with a rapid change of the 8.x present driver requires great time. And there is someone who is doing the work. But, The version which was working serves as a curio and it becomes impossible to apply it with current version. In a general case, it becomes outdated in requiring time. I think that your latest contribution is very wonderful activity. I appreciate, you are contributing using time on this driver very much. Anyway, I vote one. BTW, I wanted the stable version brunch of REL 7_3..... Regards, Hiroshi Saito
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Ludek Finstrle > Sent: 14 December 2005 14:39 > To: pgsql-odbc@postgresql.org > Subject: [ODBC] Next development steps? > > Hello, > > I study the driver and there are lot of code which doesn't > work since > libpq support. (e.g.) There is support for updatable cursor > which doesn't > work (if I'm right) because it's using backend_tuples which isn't > supported. > > It seems no other (except swamped Dave and Anoop) is supporting ODBC > driver. I propose these steps: > > 1) clean the code (and UI) with drop all non-trivial features > - these features make the code unreadable and complicated with > no proper behaviour right now > - there is no error report for them since libpq support > (exclude [#1000413] Optimistic lock cannot be used with > updateable > cursors - I think updateable cursor doesn't work at all) What features do you have in mind? > 2) create better transaction support (see Marco Ristola post) > - http://archives.postgresql.org/pgsql-odbc/2005-03/msg00128.php > - http://archives.postgresql.org/pgsql-odbc/2005-03/msg00116.php OK. > 3) improve libpq support to use PQprepare, bind parameters Yes. Actually I wonder why we don't get rid of the server side prepare option and always do that (using PQprepare). > 4) full support for only_forward read-only cursor OK. > 5) create small steps in support dropped things > and so on ... > > Can we create a new development branch at least? I'm more inclined to create a stable branch and develop in tip. Can I also assume you expect to be around for a good while to work on this ambitious plan? ODBC developers are few and far between, so starting a major project can be quite a commitment for all of us. Regards, Dave.
> > 1) clean the code (and UI) with drop all non-trivial features > > - these features make the code unreadable and complicated with > > no proper behaviour right now > > - there is no error report for them since libpq support > > (exclude [#1000413] Optimistic lock cannot be used with > > updateable > > cursors - I think updateable cursor doesn't work at all) > > What features do you have in mind? All which use backend_tuples or is unreachable at least. I'm sorry I don't have a list. It is only my ideas based on what I see through patching. I also try to start cleaning code and I always stop becouse I go to updateable cursor implementation or DRIVER_CURSOR or something similar. > I'm more inclined to create a stable branch and develop in tip. I'm sorry I'm unable to translate "develop in tip". I think that we use current stable version as start point for development branch. I don't think we could share code between this two branches. It doesn't lead to better (readable) code. > Can I also assume you expect to be around for a good while to work on > this ambitious plan? ODBC developers are few and far between, so > starting a major project can be quite a commitment for all of us. Yes. I'm planning this mainly for me (maybe someone join me/us). Regards, Luf
I believe I can find some time to hang around here.
Regards,
Siva Kumar.K
-----Original Message-----
From: Ludek Finstrle [mailto:luf@pzkagis.cz]
Sent: Wednesday, December 14, 2005 10:34 PM
To: Dave Page
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Next development steps?
> > 1) clean the code (and UI) with drop all non-trivial features
> > - these features make the code unreadable and complicated with
> > no proper behaviour right now
> > - there is no error report for them since libpq support
> > (exclude [#1000413] Optimistic lock cannot be used with
> > updateable
> > cursors - I think updateable cursor doesn't work at all)
>
> What features do you have in mind?
All which use backend_tuples or is unreachable at least.
I'm sorry I don't have a list. It is only my ideas based on
what I see through patching. I also try to start cleaning code
and I always stop becouse I go to updateable cursor implementation
or DRIVER_CURSOR or something similar.
> I'm more inclined to create a stable branch and develop in tip.
I'm sorry I'm unable to translate "develop in tip".
I think that we use current stable version as start point for
development branch. I don't think we could share code between this
two branches. It doesn't lead to better (readable) code.
> Can I also assume you expect to be around for a good while to work on
> this ambitious plan? ODBC developers are few and far between, so
> starting a major project can be quite a commitment for all of us.
Yes. I'm planning this mainly for me (maybe someone join me/us).
Regards,
Luf
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
**********************************************************
The information contained in, or attached to, this e-mail, contains confidential information and is intended solely for
theuse of the individual or entity to whom they are addressed and is subject to legal privilege. If you have received
thise-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and
notifyyour system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The
viewsor opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the
company.The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no
liabilityfor any damage caused, directly or indirectly, by any virus transmitted in this email
************************************************************
> -----Original Message----- > From: Sivakumar K [mailto:sivakumark@aztec.soft.net] > Sent: 14 December 2005 17:12 > To: Ludek Finstrle; Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: RE: [ODBC] Next development steps? > > > I believe I can find some time to hang around here. > Great, thanks - will be useful to have you around :-) BTW, have you moved from Pervasive? (Luf; Sivakumar worked with Anoop on the libpq conversion). Regards, Dave
> > Yes. I'm planning this mainly for me (maybe someone join me/us). > > Regards, > > Luf > Although i'm not an expert C programmer (and i have a lot to understand about the ODBC API) maybe i can help at least as bug hunter... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
-----Original Message----- From: "Jaime Casanova"<systemguards@gmail.com> Sent: 14/12/05 17:24:17 To: "Ludek Finstrle"<luf@pzkagis.cz> Cc: "Dave Page"<dpage@vale-housing.co.uk>, "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org> Subject: Re: [ODBC] Next development steps? > Although i'm not an expert C programmer (and i have a lot to > understand about the ODBC API) maybe i can help at least as bug > hunter... Certainly - without bug reports we have nothing to fix :-) Regards, Dave -----Unmodified Original Message----- > > Yes. I'm planning this mainly for me (maybe someone join me/us). > > Regards, > > Luf > Although i'm not an expert C programmer (and i have a lot to understand about the ODBC API) maybe i can help at least as bug hunter... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
Hi Dave, We have not moved from Pervasive :-) I was watching the activities going on in the list (Could not get into much because was very busy) and Ludek indeed deserves an applause for his active presence in the list. In my opinion, we should look for the possibility of reworking the CC_mapping function (which maps PGresult class to QResultClass) to increase the performance. As Ludek pointed out, we must identify the code to be cleaned up in different parts of the driver. Dave, can you add Siva also to the developer list? I think he deserves it because of his great contributions to the development of the libpq version of psqlodbc, and the further enhancements. Regards, Anoop > -----Original Message----- > From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc- > owner@postgresql.org] On Behalf Of Dave Page > Sent: Wednesday, December 14, 2005 10:54 PM > To: Sivakumar K; Ludek Finstrle > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Next development steps? > > > > > -----Original Message----- > > From: Sivakumar K [mailto:sivakumark@aztec.soft.net] > > Sent: 14 December 2005 17:12 > > To: Ludek Finstrle; Dave Page > > Cc: pgsql-odbc@postgresql.org > > Subject: RE: [ODBC] Next development steps? > > > > > > I believe I can find some time to hang around here. > > > > Great, thanks - will be useful to have you around :-) > > BTW, have you moved from Pervasive? > > (Luf; Sivakumar worked with Anoop on the libpq conversion). > > Regards, Dave > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
> -----Original Message----- > From: Anoop Kumar [mailto:anoopk@pervasive-postgres.com] > Sent: 15 December 2005 05:29 > To: Dave Page > Cc: pgsql-odbc@postgresql.org; Sivakumar K; Ludek Finstrle > Subject: RE: [ODBC] Next development steps? > > Hi Dave, > > We have not moved from Pervasive :-) :-). Just wondered as Siva's email address is different from what I remember. > I was watching the activities going on in the list (Could not get into > much because was very busy) and Ludek indeed deserves an applause for > his active presence in the list. Absolutely - he seems to have been working tirelessly, and has certainly jumped straight into some quite complex bugs. > In my opinion, we should look for the possibility of reworking the > CC_mapping function (which maps PGresult class to QResultClass) to > increase the performance. As Ludek pointed out, we must identify the > code to be cleaned up in different parts of the driver. Yes, I'd was thinking about this whilst driving home last night. It seems to me that we should be able to make the PGresult a member of the QResultClass, and then just modify the accessors appropriately. Of course, it's not quite that simple, but I think it's doable. > Dave, can you add Siva also to the developer list? I think he deserves > it because of his great contributions to the development of the libpq > version of psqlodbc, and the further enhancements. Certainly - what's his pgfoundry username? Regards, Dave.
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 14 December 2005 17:04 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Next development steps? > > > > 1) clean the code (and UI) with drop all non-trivial features > > > - these features make the code unreadable and complicated with > > > no proper behaviour right now > > > - there is no error report for them since libpq support > > > (exclude [#1000413] Optimistic lock cannot be used with > > > updateable > > > cursors - I think updateable cursor doesn't work at all) > > > > What features do you have in mind? > > All which use backend_tuples or is unreachable at least. > I'm sorry I don't have a list. It is only my ideas based on > what I see through patching. I also try to start cleaning code > and I always stop becouse I go to updateable cursor implementation > or DRIVER_CURSOR or something similar. > > > I'm more inclined to create a stable branch and develop in tip. > > I'm sorry I'm unable to translate "develop in tip". Tip == Head (or trunk in subversion). We put all the new code in head/tip, and keep the stable code in a separate branch. > I think that we use current stable version as start point for > development branch. I don't think we could share code between this > two branches. It doesn't lead to better (readable) code. I think that should be assessed on a per-patch basis. If there is a bug that can be fixed in the stable branch with low risk of causing other problems, then it should be fixed. If it's specific to the new code, or high risk, then it should only be fixed in head. > > Can I also assume you expect to be around for a good while > to work on > > this ambitious plan? ODBC developers are few and far between, so > > starting a major project can be quite a commitment for all of us. > > Yes. I'm planning this mainly for me (maybe someone join me/us). Well, it seems that the Pervasive guys are back again, and we've had offers to help with bug hunting :-) Regards, Dave.
On Wed, Dec 14, 2005 at 04:41:57PM -0000, Dave Page wrote: > > Can we create a new development branch at least? > > I'm more inclined to create a stable branch and develop in tip. Having suffered through doing development in a branch before; trust me, you want to do development in HEAD and not in a branch. Doing it in a branch is an outstanding way to turn things into a real mess... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> > In my opinion, we should look for the possibility of reworking the > > CC_mapping function (which maps PGresult class to QResultClass) to > > increase the performance. As Ludek pointed out, we must identify the > > code to be cleaned up in different parts of the driver. > > Yes, I'd was thinking about this whilst driving home last night. It > seems to me that we should be able to make the PGresult a member of the > QResultClass, and then just modify the accessors appropriately. Of > course, it's not quite that simple, but I think it's doable. Yes, I was thinking about this. And it need some brainstorm ... When you use declare/fetch there can be more PGresults or what about type conversion (you can take data number of time) and so on. But I'm unable to orient in code becouse a lot of them is unusable (I think PQprepare, PQexec with binding params can reduce the code a lot). I call for cleaning the code (even at the expense of some feture lost) at first. Luf
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 16 December 2005 12:51 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Next development steps? > > > > In my opinion, we should look for the possibility of reworking the > > > CC_mapping function (which maps PGresult class to QResultClass) to > > > increase the performance. As Ludek pointed out, we must > identify the > > > code to be cleaned up in different parts of the driver. > > > > Yes, I'd was thinking about this whilst driving home last night. It > > seems to me that we should be able to make the PGresult a > member of the > > QResultClass, and then just modify the accessors appropriately. Of > > course, it's not quite that simple, but I think it's doable. > > Yes, I was thinking about this. And it need some brainstorm ... > When you use declare/fetch there can be more PGresults or > what about type conversion (you can take data number of time) > and so on. Yep, both valid points. > But I'm unable to orient in code becouse a lot of them is unusable > (I think PQprepare, PQexec with binding params can reduce the > code a lot). OK. > I call for cleaning the code (even at the expense of some feture lost) > at first. I'm not against the idea in principle, but I think we need to discuss each feature proposed for removal beforehand. Regards, Dave
> > I think that we use current stable version as start point for > > development branch. I don't think we could share code between this > > two branches. It doesn't lead to better (readable) code. > > I think that should be assessed on a per-patch basis. If there is a bug > that can be fixed in the stable branch with low risk of causing other > problems, then it should be fixed. If it's specific to the new code, or > high risk, then it should only be fixed in head. You're right of course. But if everything goes as I expect then the development version is much different from stable ... I don't wait all of you agree so I tried small steps ;-) > > Yes. I'm planning this mainly for me (maybe someone join me/us). > > Well, it seems that the Pervasive guys are back again, and we've had > offers to help with bug hunting :-) Nice to hear. It's better than I expect. For Jaime Casanova: bug hunting is needed as Dave wrote. I think over psqlODBC (regression) test suite in addition. I hope it isn't so hard (but time consuming). You complimented me and I have to cut down the time for psqlodbc development during Xmas becouse I have to reinstall, upgrade and feature grow the server and all clients workstations till people go back to work at 3. January 2006. I hope I find one or two hours per two or three days. I expect I'll be at work for 12 hours (or even more) per day ... Regards, Luf
> > I call for cleaning the code (even at the expense of some feture lost) > > at first. > > I'm not against the idea in principle, but I think we need to discuss > each feature proposed for removal beforehand. I take a look at cleaning backend_tuples (as it isn't used) and I see I'll remove this features (not working now): - updateable cursor - driver cursor implementation (keysets) - we support only forward only cursor and static cursor after cleaning - the support for other cursor kinds is broken now I see nothing more but I don't go throught this cleaning yet becouse I don't want to do needless work. Do you agree with removing this features? Regards, Luf
On 20/12/05 7:45 pm, "Ludek Finstrle" <luf@pzkagis.cz> wrote: >>> I call for cleaning the code (even at the expense of some feture lost) >>> at first. >> >> I'm not against the idea in principle, but I think we need to discuss >> each feature proposed for removal beforehand. > > I take a look at cleaning backend_tuples (as it isn't used) and I see > I'll remove this features (not working now): > > - updateable cursor Hmm, that is the last major feature that Hiroshi was working on before he had to move on. How broken is it in reality? I'm loathe to remove it if it's just the few remaining issues that he would have probably fixed in a fairly short time anyway. > - driver cursor implementation (keysets) > - we support only forward only cursor and static cursor after cleaning > - the support for other cursor kinds is broken now OK. > I see nothing more but I don't go throught this cleaning yet becouse > I don't want to do needless work. Of course. Another one to consider is whether or not there is anything to gain from client side prepare. The eventual aim is to use Pqprepare and PQexecPrepared of course, but I wonder if there is any short term gain in simplicity to be had by removing the client side code sooner rather than later. Regards, Dave
> > I take a look at cleaning backend_tuples (as it isn't used) and I see > > I'll remove this features (not working now): > > > > - updateable cursor > > Hmm, that is the last major feature that Hiroshi was working on before he > had to move on. How broken is it in reality? If I understand it well this depends on driver cursor implementation (keysets). The libpq changes broke it. It use backend_tuples which isn't supported now at all. I don't know how much is it broken. This is reason why I call for branching. We keep it in stable branch. We simplify the development code and when we want implement this feature back we have stable branch from which we can study Hiroshi implementation. > > I see nothing more but I don't go throught this cleaning yet becouse > > I don't want to do needless work. > > Of course. Another one to consider is whether or not there is anything to > gain from client side prepare. The eventual aim is to use Pqprepare and > PQexecPrepared of course, but I wonder if there is any short term gain in > simplicity to be had by removing the client side code sooner rather than > later. I don't want replay problems from libpq implementation. Libpq changes broke cursor implementations. Cursors (keyset, updateable) doesn't work since this changes. What's the problem with removing it from development code? There is no bug report (as I know instead of your own - from 7 November). The problem is we're changing core without knowledge of higher level (change PQexec ... without knowledge how cursors depends on it ...). It'll be easier and quicker to implement PQprepare, better transaction support, internal unicode support, etc when the code is clean. There is a lot of code which isn't reachable now. Why we take a care on broken code in development? Regards, Luf
On 21/12/05 10:04 am, "Ludek Finstrle" <luf@pzkagis.cz> wrote: >>> I take a look at cleaning backend_tuples (as it isn't used) and I see >>> I'll remove this features (not working now): >>> >>> - updateable cursor >> >> Hmm, that is the last major feature that Hiroshi was working on before he >> had to move on. How broken is it in reality? > > If I understand it well this depends on driver cursor implementation > (keysets). The libpq changes broke it. It use backend_tuples which > isn't supported now at all. I don't know how much is it broken. > > This is reason why I call for branching. We keep it in stable branch. > We simplify the development code and when we want implement this > feature back we have stable branch from which we can study Hiroshi > implementation. OK - I just want to be sure we're not causing more work than is necessary. >>> I see nothing more but I don't go throught this cleaning yet becouse >>> I don't want to do needless work. >> >> Of course. Another one to consider is whether or not there is anything to >> gain from client side prepare. The eventual aim is to use Pqprepare and >> PQexecPrepared of course, but I wonder if there is any short term gain in >> simplicity to be had by removing the client side code sooner rather than >> later. > > I don't want replay problems from libpq implementation. Libpq changes > broke cursor implementations. Cursors (keyset, updateable) doesn't > work since this changes. What's the problem with removing it from > development code? There is no bug report (as I know instead of your > own - from 7 November). I logged the bug after getting multiple reports from end users. > The problem is we're changing core without knowledge of higher level > (change PQexec ... without knowledge how cursors depends on it ...). > > It'll be easier and quicker to implement PQprepare, better transaction > support, internal unicode support, etc when the code is clean. There > is a lot of code which isn't reachable now. > Why we take a care on broken code in development? No reason at all - like I said, I just want to be sure that removing it now, then re-implementing it will definitely be less work than fixing it in place. OK, so to get things moving, I think we should look to release a stable version (08.01.0200) as soon as possible, and then branch a stable version from that. Are there any outstanding issues to resolve/commit before we can think about doing that? The only one I can think of is Tom's 64bit concerns which I really think we need to fix first, but requires a suitable machine to properly test on of course. Regards, Dave
> OK, so to get things moving, I think we should look to release a stable > version (08.01.0200) as soon as possible, and then branch a stable version > from that. Are there any outstanding issues to resolve/commit before we can > think about doing that? The only one I can think of is Tom's 64bit concerns > which I really think we need to fix first, but requires a suitable machine > to properly test on of course. I don't think release have to wait for this one. There are known bugs: - report for sqlstate (1000495) - I try to solve it now. + 1 waiting - SEGFAULT during SQLCancel (1000475) + 0 waiting - private announce about problems with Text larger than X bytes + 1 waiting I don't know what all you want to give into new release. There is also two cleanup patches after psqlodbc-8.01.0105 which isn't tested by users. I think we can't apply these cleanup patches to stable version. It show us a little bit more backend_tuples behaviour. Regards, Luf
> -----Original Message----- > From: Ludek Finstrle [mailto:luf@pzkagis.cz] > Sent: 21 December 2005 11:53 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Next development steps? > > > OK, so to get things moving, I think we should look to > release a stable > > version (08.01.0200) as soon as possible, and then branch a > stable version > > from that. Are there any outstanding issues to > resolve/commit before we can > > think about doing that? The only one I can think of is > Tom's 64bit concerns > > which I really think we need to fix first, but requires a > suitable machine > > to properly test on of course. > > I don't think release have to wait for this one. I do, because Tom will be needing a good release for inclusion in FC5, otherwise it may end up being rolled back to an 07.xx release if he thinks the problem is too risky to release (which it sounds like he does). > There are known bugs: > - report for sqlstate (1000495) - I try to solve it now. > + 1 waiting > - SEGFAULT during SQLCancel (1000475) > + 0 waiting > - private announce about problems with Text larger than X bytes > + 1 waiting OK. > I don't know what all you want to give into new release. Not sure what you mean? > There is also two cleanup patches after psqlodbc-8.01.0105 which isn't > tested by users. I think we can't apply these cleanup patches to > stable version. It show us a little bit more backend_tuples behaviour. OK, I'm not worried about cleanups as long as it is as bug-free as possible. Regards, Dave
On 21/12/05 1:39 pm, "Ludek Finstrle" <luf@pzkagis.cz> wrote: >>> I don't think release have to wait for this one. >> >> I do, because Tom will be needing a good release for inclusion in FC5, >> otherwise it may end up being rolled back to an 07.xx release if he >> thinks the problem is too risky to release (which it sounds like he >> does). > > Ok. I didn't know this informations. But I can try it in January at first. > What's the deadline? Don't know. Last time we spoke there had been some delays, but that was a while back. I'm assuming you need this fixed for FC5 Tom - what's the current deadline? > It looks to me that psqlodbc-08.01.0105 with bug 1000475 solved is > the most stable since libpq conversion. It's certainly looking that way, thanks to you. > But the most features has 07.03.255 from Hiroshi Saito. > When we create new stable branch why don't create one for 07.03? And do what with it? It's code that has deviated significantly from the main tree, has never been released by us, and is as far as I'm aware, largely untested, certainly by the general community. In addition, the architecture is basically that which we're in the middle of ripping out and rewriting. >> OK, I'm not worried about cleanups as long as it is as bug-free as >> possible. > > I don't worry about bugs but about losing next steps to updateable cursor. I mean the stable release - that should be as bug free as possible. Regards, Dave
> > I don't think release have to wait for this one. > > I do, because Tom will be needing a good release for inclusion in FC5, > otherwise it may end up being rolled back to an 07.xx release if he > thinks the problem is too risky to release (which it sounds like he > does). Ok. I didn't know this informations. But I can try it in January at first. What's the deadline? > > There are known bugs: > > - report for sqlstate (1000495) - I try to solve it now. > > + 1 waiting Solved (I hope). > > - SEGFAULT during SQLCancel (1000475) > > + 0 waiting > > - private announce about problems with Text larger than X bytes > > + 1 waiting I hope I'll solve it before the end of week. > > I don't know what all you want to give into new release. > > Not sure what you mean? It looks to me that psqlodbc-08.01.0105 with bug 1000475 solved is the most stable since libpq conversion. I don't use cleanups as I wrote before. But the most features has 07.03.255 from Hiroshi Saito. When we create new stable branch why don't create one for 07.03? > OK, I'm not worried about cleanups as long as it is as bug-free as > possible. I don't worry about bugs but about losing next steps to updateable cursor. Regards, Luf
Dave Page <dpage@vale-housing.co.uk> writes:
> Don't know. Last time we spoke there had been some delays, but that was a
> while back. I'm assuming you need this fixed for FC5 Tom - what's the
> current deadline?
The next FC5 deadline is test2 freeze on 9 Jan. So if you make a
release in the next week or two, I can sneak it into that. If not,
there's still some margin for error, because there will be a test3 a
month later, and updates that are just bug fixes should still be
fair game at that point.
regards, tom lane
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 21 December 2005 15:25 > To: Dave Page > Cc: Ludek Finstrle; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Next development steps? > > Dave Page <dpage@vale-housing.co.uk> writes: > > Don't know. Last time we spoke there had been some delays, > but that was a > > while back. I'm assuming you need this fixed for FC5 Tom - > what's the > > current deadline? > > The next FC5 deadline is test2 freeze on 9 Jan. So if you make a > release in the next week or two, I can sneak it into that. If not, > there's still some margin for error, because there will be a test3 a > month later, and updates that are just bug fixes should still be > fair game at that point. OK, thanks Tom. Regards, Dave.