> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto
gsql-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...3/msg00128.php
> - http://archives.postgresql.org/pgsql...3/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.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster