Re: Driver maintenance continuation

I agree, that it is important to keep maintaining this driver continuously.
Let's focus on the existing driver now.
On my opinion, this driver needs support for a long time, even after
there is
a replacement.

The email reply blocker into this list is somewhere in the following
organization: http://www.ssp.df.gob.mx/htmls/home.html
My emails are classified to be infected by
"Nombre del virus: W32/Netsky(dot)p(at)MM!zip"
The email address raul(dot)delgado(at)ssp(dot)df(dot)gob(dot)mx is invalid.
With my nonexisting spanish it is hard to find another contact person.
It's great, that the spanish word "virus" is easy to understand :)

I wrote about savepoints lately.

Personally I would like about the following savepoint support change:

Create files bgtransaction.h and bgtransaction.c.
Move backend's transaction state knolege management into
a new structure BGTransaction *.
struct BGTransaction * would know the following answers:

- We need to know the backend's transaction state: in transaction, in
autocommit.
- We need to know, if the backend is in ERROR state waiting a rollback
or a savepoint rollback.
- We need to know the transaction stack consisting of BEGIN call
and all savepoints with their names.
- We need to know all opened cursors in each savepoint.
- We need to maintain the stack of transaction savepoints:
- remove a savepoint, keeping it's cursors.
- rollback a savepoint, discarding it's cursors.
- Committing means closing all opened
cursors in that transaction.
Cursors that are opened outside of any transaction, are saved.

BGTransaction * could implement the following kinds of simple functions:

BeginTransaction(bgtr,conn)
BeginSavepoint(bgtr,conn,name)
RollbackToSavepoint(bgtr,conn,name)
ReleaseSavepoint(bgtr,conn,name)
RollbackTransaction(bgtr,conn)
CommitTransaction(bgtr,conn)

InsertCursor(bgtr,conn,name)
RemoveCursor(bgtr,conn,name)
IsCursorOpen(bgtr,conn,name)
SetTransactionMode(bgtr,mode)
mode=GetTransactionMode(bgtr)
IsInRollbackNeededState(bgtr)

These functions would call CC_send_query when necessary to do the work,
or a lower level query sending function.

Because we want to delay the BEGIN, we could change CC_send_query()
so, that it would fetch the yet to be done BEGIN from the transaction,
when necessary.
No other place would need to be tweaked (i hope).

The following things could be outside of the BGTransaction *,
because they describe the transaction usage state, and not the backend
state:

- Is autocommit setting on or off for the connection?
- Is the transaction opening created with an internal command, or
manually via SQLExecute()?

If there are 30 transaction checking calls, that could be decreased into 5
with inserting two lines into CC_send_query, it would help maintainability.

So my focus here is to take a good set of transaction states and move
them from connection.h into bgtransaction.h so, that the number
of transaction checks in the driver would decrease dramatically, if
possible.
As a side effect, with the nice transaction management object,
a support for savepoints would be complete, according to the 8.0.1 specs
and understandable code in the ODBC driver.

Do you think, that this is impossible?
With the above structure abstraction, it might be doable, or not?
(I didn't use the psqlodbc coding style here.)
The above description is not complete. That describes my idea about
a good implementation.

I will post today, if I have time, a rewrite idea for convert.c and
convert.h

Marko Ristola

Bruce Momjian wrote:

>Joshua D. Drake wrote:
>
>
>>On Tue, 2005-03-29 at 19:57 +0200, Philippe Lang wrote:
>>
>>
>>>The driver history since Hiroshi left, more than one year ago I think,
>>>shows clearly that a fresh rewrite was necessary. I'm really happy that
>>>you took this decision. Thanks again Joshua. I'm not sure we can really
>>>help in another way than beta testing, but who knows. Is there maybe
>>>something we can do regarding internationalization?
>>>
>>>
>>I think the best way people will be able to help initially will be
>>testing and internationalization.
>>
>>Once the driver is actually released, peer review is always good as
>>well as overall just participation within the lists etc...
>>
>>
>
>Until we know the exact license that will be used we should just keep
>focusing on our existing driver. Saying it is going to be "open source"
>isn't enough of a guarantee that the their new driver will be acceptable
>to the community. It might have an advertizing clause, or have some
>other restrictions.
>
>
>