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) AS
SELECT * FROM tenk1 WHERE string4 = $1 AND (four = $2 OR
ten = $3::bigint OR 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(at)wheeler(dot)net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org