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 JAA60216
	for <pgsql-interfaces@postgresql.org>;
	Tue, 7 Mar 2000 09:47:10 -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); Tue, 7 Mar 2000 08:47:55 -0600
Sender: ed
Message-ID: <38C51719.8306A08D@austin.rr.com>
Date: Tue, 07 Mar 2000 08:50:01 -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: "pgsql-interfaces@postgreSQL.org" <pgsql-interfaces@postgresql.org>
Subject: [INTERFACES] Re: [DELIVERY FAILURE: User laszlo_acs
	(laszlo_acs@cms.state.il.us)...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Would one of the pgsql-interfaces list administrators consider
removing laszlo_acs@cms.state.il.us from the pgsql-interfaces mailing
list?  His mail is bouncing seemingly on every submission to the list.

Regards,
Ed Loehr

Postmaster@state.il.us wrote:
> 
> Your message
> 
>   Subject: Re: [INTERFACES] Re: Quick perl question
> 
> was not delivered to:
> 
>   laszlo_acs@cms.state.il.us
> 
> because:
> 
>   User laszlo_acs (laszlo_acs@cms.state.il.us) not listed in public Name & Address Book
> 
>   ----------------------------------------------------------------------
> Reporting-MTA: dns;cms.state.il.us
> 
> Final-Recipient: rfc822;laszlo_acs@cms.state.il.us
> Action: failed
> Status: 5.1.1
> Diagnostic-Code: X-Notes; User laszlo_acs (laszlo_acs@cms.state.il.us) not listed in public Name & Address Book
> 
>   ----------------------------------------------------------------------
> 
> Subject: Re: [INTERFACES] Re: Quick perl question
> Date: Mon, 06 Mar 2000 14:33:15 -0600
> From: Ed Loehr <eloehr@austin.rr.com>
> To: <bweaver@tranquility.net>
> CC: <pgsql-interfaces@postgreSQL.org>
> 
> > 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
> 
> ************