DBD::PostgreSQL

Dear Fellow DBI and PostgreSQL Hackers,

Apologies for cross-posting, but I figure that some of my questions can 
be better answered by DBI folks, while others can be better answered by 
PostgreSQL interface folks.

Since Tim pointed out that DBD::Pg hasn't been updated to use DBI's 
Driver.xst, I've taken it upon myself to try to update it to do so. 
However, since a) I've never programmed XS before; and b) I've never 
programmed C before; and c) I didn't want to just totally hork the 
DBD::Pg sources, I took it upon myself to try creating a new PostgreSQL 
driver from scratch.

The good news is that I think I'm making pretty decent progress, and I 
may well be able to get something workable in a few weeks. It's turning 
out that C isn't quite as tough to work with as my years-long mental 
block has led me to believe. Of course, it's made easier by the nicely 
done DBI::DBD document, as well as the great existing implementations 
for MySQL, ODBC, and Oracle. So I've been cutting and pasting with glee 
from the DBD::mysql and DBD::Pg sources, and I think it could add up to 
something pretty good before long.

All that is a long-winded way of leading up to some questions I've been 
having as I've worked through the sources. The questions:

* In DBD::Pg's dbdimp.c, the dbd_db_commit() function attempts a 
commit, and if it's successful, it then starts another transaction. Is 
this the proper behavior? The other DBDs I looked at don't appear to 
BEGIN a new transaction in the dbd_db_commit() function.

* A similar question applies to dbd_db_rollback(). It does a rollback, 
and then BEGINs a new transaction. Should it be starting another 
transaction there?

* How is DBI's begin_work() method intended to influence commits and 
rollbacks?

* Also in dbd_db_commit() and dbd_db_rollback(), I notice that the last 
return statement returns 0. Shouldn't these be returning true?

* In DBD::Pg's dbdimp.c, the dbd_db_disconnect() function automatically 
does a rollback if AutoCommit is off. Should there not be some way to 
tell that, in addition to AutoCommit being off, a transaction is 
actually in progress? That is to say, since the last call to 
dbd_db_commit() that some statements have actually been executed? Or 
does this matter?

* In dbd_db_destroy(), if I'm using Driver.xst, I don't actually need 
to execute this code, correct?
    if (DBIc_ACTIVE(imp_dbh)) {        dbd_db_disconnect(dbh, imp_dbh);    }

* In dbd_db_STORE_attrib(), DBD::Pg is doing the necessary stuff when 
AutoCommit is set to COMMIT and BEGIN transactions. If the answers to 
the above questions about dbd_db_commit() and dbd_db_rollback() 
indicate that they can stop BEGINing transactions, couldn't those 
functions be called inside dbd_db_STORE_attrib() instead of 
dbd_db_STORE_attrib() duplicating much of the same code?

* Also in dbd_db_STORE_attrib(), I note that DBD::Pg's 
imp_dbh->init_commit attribute is checked and set. Isn't this 
redundant, since we already have AutoCommit? Or could this attribute 
actually be used to tell something about the *status* of a transaction? 
(AFAICT, it currently isn't used that way, and is simply redundant).

* And finally, is dbd_preparse() totally necessary? I mean, doesn't 
PostgreSQL's PQexec() function do the necessary parsing? Jeffrey Baker 
mentioned to me that he was working on a new parser, and perhaps I'm 
missing something (because of parameters?), but I'm just trying to 
figure out why this is even necessary.

* One more thing: I was looking at the PostgreSQL documents for the new 
support for prepared statements in version 7.3. They look like this:

PREPARE q3(text, int, float, boolean, oid, smallint) ASSELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 ORten =
$3::bigintOR true = $4 OR oid = $5 OR odd = $6::int);
 

(BTW, I can see why preparsing would be necessary here!) Now, if I'm 
understanding this correctly, the PREPARE statement would need to have 
the data types of each of the parameters specified. Is this something 
that's done in other DBI drivers?

Okay, sorry for all the questions. My motivation is to make a new 
PostgreSQL DBI driver that's one of the best DBI drivers around. Any 
help would go a long way toward helping me to reach my goal.

TIA,

David

-- 
David Wheeler                                     AIM: dwTheory
david@wheeler.net                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e                                               Jabber:
Theory@jabber.org