> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailtogsql-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

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

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

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