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

Re: DBD::PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Wheeler <david(at)wheeler(dot)net>
Cc: dbi-dev(at)perl(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: DBD::PostgreSQL
Date: 2002-11-18 16:19:25
Message-ID: 29660.1037636365@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
David Wheeler <david(at)wheeler(dot)net> writes:
> On Sunday, November 17, 2002, at 10:15  PM, Tom Lane wrote:
>> Both of these seem pretty bogus to me.  Ideally the driver should not
>> issue a "begin" until the application issues the first command of the
>> new transaction.  Otherwise you get into scenarios where idle
>> connections are holding open transactions, and ain't nobody gonna be
>> happy with that.

> Okay. I think I'll use a flag in the driver to track when it's in a 
> transaction, and do the right thing in the begin and rollback functions.

I think someone else said that the DBD framework already includes such a
flag ("BegunWork"?) --- if so, you should surely use that one.

> So, if I understand you correctly, PostgreSQL's PREPARE statement 
> *requires* data typing in its syntax?

Yup.

> If so, is there an 
> easy/straight-forward way to ask the server what the data types for 
> each column are before executing the PREPARE?

There are various ways to retrieve the datatypes of the columns of a
table, but I'm not sure how that helps you to determine the parameter
types for an arbitrary SQL command to be prepared.  Are you assuming
a specific structure of the command you want to prepare?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: David WheelerDate: 2002-11-18 16:27:33
Subject: Re: DBD::PostgreSQL
Previous:From: Curtis FaithDate: 2002-11-18 16:16:56
Subject: Re: btree shrinking again

pgsql-interfaces by date

Next:From: David WheelerDate: 2002-11-18 16:27:33
Subject: Re: DBD::PostgreSQL
Previous:From: David WheelerDate: 2002-11-18 16:16:03
Subject: Re: DBD::PostgreSQL

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