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