Re: [INTERFACES] DBD::PostgreSQL

[David Wheeler]

On Sunday, November 17, 2002, at 08:21  PM, Thomas A. Lowery wrote:

This is great to hear ... possible name of PgXS? (not that the current
version isn't using XS), allows both Pg and the new Pg (along with PgSPI) to
be installed at once.

Well, if the name needs to change, I was thinking of DBD::PgSQL. Is someone working on DBD::PgSPI? That might be even more valuable, since that appears to be a much more robust API.

Learning under fire, the best way!

Yes...or I'm a crazy bastard. Take your pick.

Yes, when AutoCommit is on, each statement is committed after execution.
DBD::ADO uses an ADO function that starts a new transaction after a successful
commit or rollback of the current. It's switching between the two states that
gets difficult to handle (also supporting database types that do not support
transactions).

So in DBD::ADO, you're not actually deferring starting a new transaction until it's actually needed? Are there no problems with idle transactions?

IMHO: begin_work for Pg simply turns AutoCommit off. The AutoCommit handles
committing the current transaction and starting the next.

Okay.

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

Success is non-zero. However, $dbh->err is 0 or undefined.

Info from DBI doc:
  "commit"
	$rc  = $dbh->commit     or die $dbh->errstr;

Yes. However, dbd_db_commit() and dbd_db_rollback() can return false without throwing an error. I think that's a mistake.

IMHO: It's much safer to rollback (unconditionally) on disconnect, then
attempting to manage tracking the current action taken in the
transaction by the different statement handlers.

Don't all statement ultimately go through dbd_st_execute()? If so, then I think it'd be relatively easy to just start the transaction when its needed, and then dbd_db_disconnect() can check for a flag indicating whether a transaction is actually in progress or not.

AFAIK:  All the drivers support dbd_preparse.

Okay, got it.

Ouch ... that may make things ugly.

Amen.

It'll give you fewer nightmares if you can pass the "statement" to
the back-end to prepare, having the back-end return the number of
parameters, and data types. (I haven't looked at the 7.3 PostgreSQL
documentation yet). If the back-end doesn't support this type of
prepare, then you may need to pre-parse the statement to determine
what placeholders are requires and attempt to determine the correct
data types.

AFAIK, there currently is no API for this, but I think that this exchange might have tickled some ideas among the PostgreSQL developers... :-)

Regards,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]