Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
	by hub.org (8.9.3/8.9.3) with ESMTP id PAA80479
	for <pgsql-interfaces@postgresql.org>;
	Mon, 6 Mar 2000 15:30:20 -0500 (EST)
	(envelope-from eloehr@austin.rr.com)
Received: from austin.rr.com ([24.93.58.117]) by mail.austin.rr.com with
	Microsoft SMTPSVC(5.5.1877.197.19); Mon, 6 Mar 2000 14:31:07 -0600
Sender: ed
Message-ID: <38C4160B.E259A40C@austin.rr.com>
Date: Mon, 06 Mar 2000 14:33:15 -0600
From: Ed Loehr <eloehr@austin.rr.com>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: bweaver@tranquility.net
CC: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] Re: Quick perl question
References: <38C3F131.215DB6A5@amgen.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> I also would like to echo the comments that someone else has made about using
> DBI::DBD rather than Pg.  Pg works well and is slightly easier to get working,
> but that is because the complexity of DBI::DBD adds some useful stuff not
> present in Pg. In particular, the error trapping is great. On the down side, it
> gets tedious writting each query as two parts: "prepare" and "execute".  This is
> compensated for in overall portability to other DBMS, I think.

You may also avoid that downside by encapsulating prepare() and
execute(), eg. 

	sub mySelect {
	    ...
	    prepare...
	    execute...
	    ...
	}

Regards,
Ed Loehr