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-
