Pascal Pochet, March 24, 2021 - 8:28 am UTC
As I told in my original question, the dynamic pivot is just an example (you could have a noop functionality, the problem will still be there), I am actually busy with another function of my own that does not do a PIVOT at all but uses the basic mechanism found in the dynamic pivot example,
and the problem is related to the presence of a FLOAT in the SELECT parsed by the ODCI engine: the fact that you got an undocumented type (4) in the ODCITableStart when calling sctx.ret_type.getattreleminfo while it was reported correctly as a NUMBER in ODCITableDescribe when calling DBMS_SQL.DESCRIBE_COLUMNS2, is the issue, and actually looks like a bug.
(of course if a cast as number in the original query, the problem is solved, but not possible in all cases where I don't control the data model)
March 26, 2021 - 6:57 am UTC
Could you give us *your* situation then, so we can explore that further
A reader, March 26, 2021 - 2:02 pm UTC
March 31, 2021 - 4:36 am UTC
I already said I replicated your issue.
My question is - I'd like to see a *context* around why you want to use this technique without any aggregation, ie, the business case.
A reader, April 07, 2021 - 12:32 pm UTC
As I told you the PivotImpl was the starting point of the development I used to do something else. The actual need was dynamic query as shown in the Live SQL example and trying to avoid to create TYPE AS OBJECT and TABLE OF for each possible result set we may encounter in a context of "dynamic views" (pipelined functions)...
(these functions are used to check the results of reports created by TABLEAU on a Document database before they go life…)