Re: Next development steps?

> > 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