Re: Last minute mini-proposal (I know, I know) forPQexecf() - Mailing list pgsql-hackers

From
Subject Re: Last minute mini-proposal (I know, I know) forPQexecf()
Date
Msg-id 1175348056.6784.43.camel@sakai.localdomain
Whole thread Raw
In response to Re: Last minute mini-proposal (I know, I know) for PQexecf()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Last minute mini-proposal (I know, I know) forPQexecf()
List pgsql-hackers
<blockquote type="CITE"><pre>
<font color="#000000">Way too late for 8.3 --- if we were going to do something like this,</font>
<font color="#000000">we should think first and program later.  In particular, blindly</font>
<font color="#000000">adopting the sprintf format string definition doesn't seem very helpful.</font>
<font color="#000000">The sorts of escapes I'd want to have are "properly quoted SQL</font>
<font color="#000000">identifier", "properly quoted SQL literal", etc.  A large fraction of</font>
<font color="#000000">what sprintf knows about is more or less irrelevant to the task of</font>
<font color="#000000">creating SQL commands.</font>

<font color="#000000">Also, how does this interact with parameterized or prepared commands?</font>
<font color="#000000">If we wanted PQexecf we'd soon want PQexecParamsf, etc.  I don't think</font>
<font color="#000000">we really want so much duplicate logic there --- it'd be better to</font>
<font color="#000000">decouple the string-building functionality from the query-sending</font>
<font color="#000000">functionality.  Probably better to consider something like</font>
<font color="#000000">PQformatQuery() that passes back a malloc'd string.</font>
</pre></blockquote><br /> I agree with almost everything that you said.  I <i>really</i> like the idea of new format
specifiersfor "properly quoted stuff".<br /><br /> I like the idea of adding a new PQformatQuery() function. And once
youhave PQformatQuery(), you can easily change the implementation of PQexecf() without affecting any client
applications.I'm not sure that we would need a PQexecParamsf(), but I'm willing to accept that we might (it seems more
likelythat we would want PQpreparef()).<br /><br /> But we would want those features in addition to PQexecf(), not
insteadof PQexecf().<br /><br /> PQexecf() would be useful today, even without all of those extras - just look at the
thesource code for pg_dump to see how much code we would eliminate with a simple PQexecf().<br /><br /> There are two
reasonsI threw out this idea now.<br /><br /> 1) I didn't think of it until a few days ago...<br /><br /> 2) It's
importantto get the <i>interface</i> into a near-future release so that client applications can start using it soon. 
Wecan add features and refactor the implementation later.  I assume that my prototype is not horrible (it's based on
existingcode).<br /><br />             -- Korry<br /><table cellpadding="0" cellspacing="0" width="100%"><tr><td><br
/><br/> --<br />   Korry Douglas    <a href="mailto:korryd@enterprisedb.com">korryd@enterprisedb.com</a><br />  
EnterpriseDB     <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></td></tr></table> 

pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: CIC and deadlocks
Next
From: Tom Lane
Date:
Subject: Re: CIC and deadlocks