Check support for data type 8

[stoch]

This is using the OCI driver. To be compared to new odpi solution.

This turns out to be a relevant an important query (hidden and invisible columns in 12c).

SELECT table_name, column_name, data_type, data_length, column_id, default_length, data_default FROM user_tab_cols WHERE table_name = 'CONTRACT'

[ocistmt::execute:706] unsupporetd type 8

[stoch]

@KarlKeiser : This is a LONG value. It could be represented as a binary in DDerl. It would be then a matter of SQL wrappers around it to display the value in the grid (e.g. to_binstr() or other decoders applied to binary).

Please also check if the odpi driver has the same typo in this error message.

[KarlKeiser]

Looks like LONG type works in oranif and in its dderl adapter as well. I tried the following statements:

CREATE TABLE
    foo (
        a LONG
    )

INSERT INTO
    foo
VALUES
    (1.234)

SELECT
    A
FROM
    foo

And got the following result:

It even seems to work with the "usual suspect" value of 0.1:

In this screenshot, I also inserted a value of 'wwww', so the LONG type can even handle strings, for some reason. But it does actually treat numbers as such (and not just take everything as char date), which is shown by how it displays 0.1 as .1.

On the odpi level, the LONG has native type DPI_NATIVE_TYPE_BYTES and oratype DPI_ORACLE_TYPE_LONG_VARCHAR. So internally it stores it as a string, much like we do with DOUBLE now. Except it's intelligent enough to do it on its own, as opposed the DOUBLE where we had to explicitly tell it to use strings instead.

Statistics are a bit weird though:

Even when only selecting numbers, the results aren't correct:

[stoch]

@KarlKeiser I assume that LONG can have arbitrary binary data. This is why I want it to be stored and rendered like an erlang binary. So the output should be a hex string, independent of the data it contains.

[KarlKeiser]

Ok, so the data is definitely stored as binary. If I insert 0.1 and '0,1', I get this:

So the first time it translated 0.1 to '.1', and the second time it just took the '0,1' and stored it as it is.

What you're asking for is that if we read out something that is char data internally, we have to check whether the oratype is char data or a long. That's possible, but I'll have to see if I have to change the driver to pass on this information where it currently isn't going. Right now I think it just takes the native type and reads out based on that.

[KarlKeiser]

LONG data is now displayed as hex. To test this, run the following statements:

CREATE TABLE
    foo (
        a LONG
    )

INSERT INTO
    foo
VALUES
    ('abc')

SELECT
    A
FROM
    foo

This results in:

The '616263' that it displays is the hex values for the 'abc' that was inserted: