apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Donovan <donov...@bellatlantic.net>
Subject Re: Some dbd driver questions
Date Sun, 25 Mar 2007 00:54:20 GMT
Bojan Smojver wrote:
> On Sat, 2007-03-24 at 11:31 -0400, Tom Donovan wrote:
>> I've been working on an ODBC dbd driver, and I have a few questions 
>  ...
>> Finally, Most of the non-binary functions have new "b"inary equivalents:
>>    There is a _pbselect and a _pvbselect - but not a simple _bselect.
>> Is it intentional that there is no un-prepared binary select, or was 
>> this just an oversight?  One-shot (i.e. runtime generated SQL) 
>> statements don't benefit much from being prepared and then only used 
>> once.  A _bselect function would be useful.
> I didn't see the need for it, as select doesn't take any parameters, so
> distinction between binary and char parameters obviously doesn't make
> sense. You can just use regular _select() or even _p[b]select, if you
> want the non-parameter statement to be prepared. Both datum_get() and
> get_entry() can be used after all any of select/p[b]select.
Thanks Bojan.  That clears up something I had wrong.

With the non-binary select/query functions I converted all the returned 
columns to strings in anticipation of get_entry().  With the binary 
functions I retrieved them as the original datatypes in anticipation of 

With ODBC this decision usually (but not always) must be made when the 
statement is executed.  It cannot be postponed until 
get_entry()/datum_get() is actually called.

Back to the drawing board.

It sounds like I should limit get_entry() to text columns rather than 
attempt any datatype conversions.


View raw message