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: