Re: Next development steps?

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: Ludek Finstrle <luf(at)pzkagis(dot)cz>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Next development steps?
Date: 2005-12-20 21:17:25
Message-ID: BFCE2565.8114%dpage@vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

On 20/12/05 7:45 pm, "Ludek Finstrle" <luf(at)pzkagis(dot)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

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message noreply 2005-12-21 07:27:26 [ psqlodbc-Bugs-1000495 ] duplicate key causes HY000 SQL-State
Previous Message Ludek Finstrle 2005-12-20 19:45:29 Re: Next development steps?