Re: Next development steps?

On 21/12/05 10:04 am, "Ludek Finstrle" <luf(at)pzkagis(dot)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