Direct Path API need to support Oracle native datatypes, not strings only about ocilib HOT 4 CLOSED

As most of the time, direct path is used with text files, its support was made using string in OCILIB.
You're right indeed. It is a nice enhancement.

from ocilib.

Also I think it's worse to be able to handle BINARY_FLOAT, BINARY_DOUBLE the same way, though I have not faced with those types yet:
https://support.oracle.com/knowledge/Oracle%20Database%20Products/1315200_1.html

and INTERVAL types - those do work fine with current textual conversion at the moment, but taking into account that such conversion is potentially buggy - I'd copy them using DUMP()ed values as well.

from ocilib.

Final findings for today:

1. While DATE, TIMESTAMP values can be copied using
   memcpy(data, value, (size_t) size);

the NUMBER raw values need to be copied using

memcpy(data, value, (size_t) size + 1);

due subsequent

    dpcol->lens[row-1]  = size;

2. Also I was not able to find any documented example how to handle the TIMESTAMP values for Direct Path API properly, in terms of the sqlcode values - do we need to specify SQLT_ ones or actual DUMP() Types, probably it worse to debug SQL*Loader calls - gbd is able to set breakpoint on OCIAttrSet()

Accodring to the next link
https://ellebaek.wordpress.com/2011/02/25/oracle-type-code-mappings/

for NUMBER and DATE the SQLT_NUM, SQLT_DAT and DUMP()ed type codes are the same (2 and 12, respectively),

while for timestamps those differ, and each type has own behavior:

for TIMESTAMP WITH LOCAL TIMEZONE only 232 (SQLT_TIMESTAMP_LTZ) - fits, DUMP() shows 231 as result, if we initially specify 231 then OCI gives AV error.

for TIMESTAMP WITH TIMEZONE both 181 and 188 (SQLT_TIMESTAMP_TZ) work fine, DUMP() shows 181 as result but

for TIMESTAMP only 180 fits, while 187 code, i.e. SQLT_TIMESTAMP gives conversion result.
DUMP() shows 180

So there is no unambiguous way how to handle sqlcode for the TIMESTAMPs, unfortunately.

from ocilib.

Closing this issue (7 years old) as it won't be addressed in a near future.

from ocilib.