Re: libpq and prepared statements progress for 8.0 - Mailing list pgsql-hackers

From Greg Stark
Subject Re: libpq and prepared statements progress for 8.0
Date
Msg-id 87mzzswxv7.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: libpq and prepared statements progress for 8.0  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Responses Re: libpq and prepared statements progress for 8.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > PREPARE st(unknown) AS INSERT INTO foobar(a) VALUES ($1);
> 
> Using PQExecParams is completely out of the question?  How are you
> executing your statements...PQExec?

A bit of context here. The perl DBD::Pg developers are trying to figure out
how to implement prepared queries sanely. As it stands now they're basically
writing off both binary prepared queries and SQL based prepared queries as
basically useless. It would be a shame to have a brand new binary protocol but
find it ignored by driver writers.

The problem is that you want to be able to do
$sth = $dbh->prepare("SELECT col_a FROM tab WHERE col_b = ?");$sth->execute(1);...

And not have to jump through hoops binding parameters to types and so on. 

Ideally the database should treat the placeholder exactly as it would a
single-quoted constant. Ie, it should treat it as "unknown" and use the
context around it to determine what type reader function to use to read it.

That would mean the semantics would be exactly equivalent to:
SELECT col_a FROM tab WHERE col_b = '1';


Without this capability using prepared statements is simply too cumbersome for
application programmers. And in any case DBD::Pg wants to maintain backwards
compatibility with the existing drivers which don't require binding parameter
types because they simply interpolate the parameters into the query string.

-- 
greg



pgsql-hackers by date:

Previous
From: Dennis Bjorklund
Date:
Subject: Is select a transaction starting statement?
Next
From: Alvaro Herrera
Date:
Subject: Re: Is select a transaction starting statement?