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 
datum_get().

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.

-tom-



Mime
View raw message