Re: Driver maintenance continuation

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?

Regards,

Philippe Lang

-----Message d'origine-----

> It's great, if we get a rewrite of the driver:
> This driver has it's drawbacks.

Our thought was that the a fresh rewrite would provide for a better
overall driver and a more productive initial release cycle.

Our current goal is to deliver a brand new driver in August.

Sincerely,

Joshua D. Drake

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

Sincerely,

Joshua D. Drake

>
> Regards,
>
> Philippe Lang
>
> -----Message d'origine-----
>
> > It's great, if we get a rewrite of the driver:
> > This driver has it's drawbacks.
>
> Our thought was that the a fresh rewrite would provide for a better
> overall driver and a more productive initial release cycle.
>
> Our current goal is to deliver a brand new driver in August.
>
> Sincerely,
>
> Joshua D. Drake
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/

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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

Actually, now that I think of it, the Command Prompt ODBC driver is
already open source, LGPL, because it is based on our existing driver.

However, they sell it and we have never taken their changes back into
our driver or spawned a new project based on their code, so I am
wondering how them doing a new driver that is open source helps us
unless we are going to take the code and build a team around it.

---------------------------------------------------------------------------

Marko Ristola wrote:
>
> 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.
> >
> >
> >
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073