[DB-SIG] API suggestion: expose 'quote' method
davidrushby at yahoo.com
Tue Jun 3 12:45:21 EDT 2003
--- Chris Cogdon <chris at cogdon.org> wrote:
> On Tuesday, Jun 3, 2003, at 00:23 US/Pacific, M.-A. Lemburg wrote:
> > I don't buy that. By "quoting" you actually mean "binding" and you
> > thus lose all the benefits of having the SQL separated from the
> > data.
> > The good thing about binding parameters is that the user
> > does *not* have to worry about quoting (plus it usually buys
> > a performance gain for next to nothing).
> > Of course, if some APIs think it's worth exposing such a quote
> > function, they are free to do so. It shouldn't be required, though.
> Okay... let me paraphrase your argument to see if I got things straight.
> Exposing the quoting mechanism would make sense on APIs for DBMSes that
> require a single SQL string be passed. However, some DMBSes use a
> different query passing mechanism, where the SQL query with embedded
> '?' marks (or whatever) and parameters in binary format are passed
> separately. While somewhat more complicated, this is a performance gain
> as the DMBS query passer does not need to parse the parameters, nor
> does the application need to convert them into a string.
> For these types of DMBSs, quoting and binding are different operations.
> For things like PostgreSQL, they're the same.
> I would suspect that these DMBSes still have a way of representing any
> literal value inside the SQL string itself.
They ought to, but some don't allow literal representation of certain data
types--blobs and database arrays are frequent offenders.
> Now, if this is true, then the DMBS has a quoting convention that
> I believe should be exposed.
Again, "I believe should be exposed" != "actually is exposed in the client
> Yes, it lowers performance somewhat, but the alternative is to jump
> through a lot of hoops to get the separated string and parameters
> to the 'execute' method, or use a quoting function external to the
> API (which, being separate from the API layer, is error-prone).
> I'm suggesting that we make this part of the API (2.1, perhaps) so that
> there's something there my application can depend on. I believe it's an
> important part of dealing with the DMBS, and should be part of the
I'm not opposed to adding this method to the spec, as long as:
a) it's optional--some DBMSes just can't support it
b) the performance penalty applies *only* to those who explicitly choose to
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
More information about the DB-SIG