Skip site navigation (1) Skip section navigation (2)

Re: DBD::PostgreSQL

From: David Wheeler <david(at)wheeler(dot)net>
To: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Cc: dbi-dev(at)perl(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: DBD::PostgreSQL
Date: 2002-11-18 16:55:20
Message-ID: 85B2FBF1-FB16-11D6-93B3-0003931A964A@wheeler.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
On Monday, November 18, 2002, at 02:15  AM, Tim Bunce wrote:

> Many databases, like Oracle, automatically start a transaction at
> the server as soon as it's needed. The application doesn't have to
> do it explicitly. (DBD::Informix is probably a good example of a
> driver that needs to start transactions explicitly.)

I'm quite sure that in PostgreSQL, transactions have to be started 
explicitly.

> Drivers are free to defer starting a new transaction until it's needed.
> Or they can start one right away, but that may cause problems on
> the server if there are many 'idle transactions'. (Also beware that
> some databases don't allow certain statements, like some 'alter
> session ...', to be issued while a transaction is active. If that
> applies to Pg then you may have a problem.)

According to Tom Lane, idle transactions are problematic, so I think 
I'll code it up to start the transaction when its needed -- presumably 
by checking and setting the relevant flags in execute().

> drivers do *not* need to define their own begin_work method.
>
> What they _should_ do is make their commit and rollback methods
> check for BegunWork being true (it's a bit flag in the com structure)
> and if true then turn AutoCommit back on instead of starting a new 
> transaction.
>
> (If they don't do that then the DBI handles it but it's faster,
> cleaner, and safer for teh driver to do it.)

Okay, then that's what I'll do. Do I check it like this?

   if (DBIc_has(imp_dbh, DBIcf_BegunWork)) {...}

>> * Also in dbd_db_commit() and dbd_db_rollback(), I notice that the 
>> last
>> return statement returns 0. Shouldn't these be returning true?
>
> Yes, when using Driver.xst, if there's no error.

It appears that they return false when imp_dbh->conn is NULL. That 
would count as an error, I think. DBD::Pg doesn't report it as an 
error, though -- it just returns false. Should I add an appropriate 
call to do_error() in such a case?

>> 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.
>
> I'd really appreciate any feedback (ie patches :) you might have
> for the DBI::DBD document.  It's a bit thin and/or dated in places.

Yes, I've thought about that. You can at least expect a bit of clean up 
(grammar, etc.), but I might well add more. It'd probably be good to do 
so as a newbie who wants to help other newbies along...

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


In response to

Responses

pgsql-hackers by date

Next:From: David WheelerDate: 2002-11-18 16:55:34
Subject: Re: DBD::PostgreSQL
Previous:From: David WheelerDate: 2002-11-18 16:49:17
Subject: Re: DBD::PostgreSQL

pgsql-interfaces by date

Next:From: David WheelerDate: 2002-11-18 16:55:34
Subject: Re: DBD::PostgreSQL
Previous:From: David WheelerDate: 2002-11-18 16:49:17
Subject: Re: DBD::PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group