Re: DBD::PostgreSQL

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
david(at)wheeler(dot)net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org