Thread: Driver maintenance continuation
It's great, if we get a rewrite of the driver: This driver has it's drawbacks. Writing another driver takes time. We need a good driver, that works good enough with 8.0 and perhaps with 7.4.x. The current driver is now the best driver available. So I think, that maintaining this driver continuously a long time is a very good thing to PostgreSQL. Marko Ristola
Marko Ristola wrote: > > 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 > > > Writing another driver takes time. > We need a good driver, that works good enough > with 8.0 and perhaps with 7.4.x. > > The current driver is now the best driver available. > > So I think, that maintaining this driver continuously > a long time is a very good thing to PostgreSQL. > > Marko Ristola > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
This is the most important new for postgresql ODBC comunity ! Really fantastic ! ----- Original Message ----- From: "Joshua D. Drake" <jd@commandprompt.com> To: "Marko Ristola" <marko.ristola@kolumbus.fi> Cc: <pgsql-odbc@postgresql.org> Sent: Tuesday, March 29, 2005 6:04 PM Subject: Re: [ODBC] Driver maintenance continuation > Marko Ristola wrote: > >> >> 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 > > > >> >> >> Writing another driver takes time. >> We need a good driver, that works good enough >> with 8.0 and perhaps with 7.4.x. >> >> The current driver is now the best driver available. >> >> So I think, that maintaining this driver continuously >> a long time is a very good thing to PostgreSQL. >> >> Marko Ristola >> >> >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Don't 'kill -9' the postmaster > > > > -- > Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC > Postgresql support, programming shared hosting and dedicated hosting. > +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com > PostgreSQL Replicator -- production quality replication for PostgreSQL > > -------------------------------------------------------------------------------- > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org >
It's really great that you did get the job and PostgreSQL will get a new much better driver. Congratulations for you and your team members! I wrote the first message for one purpose: We need to maintain this driver until the replacement is ready. I have learned from others, that it is wise to remember to maintain the current driver until the new one is ready. So there is a need for ODBC supporters while you and your team are making the new driver. I haven't been able to improve the current driver, but I don't have detailed ODBC specs or time either. I have been thinkin about one year ago, that this driver needs something like a rewrite: I wrote about higher level ODBC objects and read/write functions from the objects into the backend messages for many different database backend versions almost one year ago (it was in the psqlodbc feature request list). With those objects, you could do something like: - insert a bunch of rows into the backend. - support different backends by isolating the backend differences into object read/write functions. So I miss higher level code on the ODBC driver. I wrote some code, but the task was overly large for me even for an extremely small workable part of the driver with my lack of time. I understood also then, that my suggestion might have been very slow because of many memory allocations ... I haven't looked at the libpq code. It is very good, that you have a good stable code base to start with. Sincerely with congratulations, Marko Ristola Joshua D. Drake wrote: > Marko Ristola wrote: > >> >> 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 > > > >> >> >> Writing another driver takes time. >> We need a good driver, that works good enough >> with 8.0 and perhaps with 7.4.x. >> >> The current driver is now the best driver available. >> >> So I think, that maintaining this driver continuously >> a long time is a very good thing to PostgreSQL. >> >> Marko Ristola >> >> >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Don't 'kill -9' the postmaster > > > >
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@candle.pha.pa.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.p@MM!zip" The email address raul.delgado@ssp.df.gob.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.p@MM!zip" > The email address raul.delgado@ssp.df.gob.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@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073