[KYUUBI #6815] fix jdbc oracle engine NUMBER(20,0) type problem

[ylq5126]

Why are the changes needed?

when oracle column type is NUMBER(20,0), and value is 530924057810571264， query tips Integer cast exception
This PR adds Column precision length check，only length <= 9 can be cast to Integer.

How was this patch tested?

Deployed and Tested in our environment. use kyuubi 1.11.1 jdbc engine proxy oracle, data can be queried normally.

Was this patch authored or co-authored using generative AI tooling?

No.

[wangzhigang1999]

Thanks for the fix. Before diving into the code, could you please tidy up the PR a bit? Since we already have a PR template, it’s best to follow it. Also, if you used any AI tools to assist with development, could you please perform an initial review following the guidelines in #7452?

[ylq5126]

Thanks for the fix. Before diving into the code, could you please tidy up the PR a bit? Since we already have a PR template, it’s best to follow it. Also, if you used any AI tools to assist with development, could you please perform an initial review following the guidelines in #7452?

ok, changed

[wangzhigang1999]

I noticed the existing Oracle tests are failing after this change. Oracle INTEGER seems to be exposed by ojdbc as NUMBER(*,0) / NUMERIC with scale 0, and its reported precision may not match precision <= 9, so it now falls through to DECIMAL. That changes resultSet.getObject() from an integer-like value to BigDecimal(1), causing the assertions in OracleStatementSuite to fail.

Would it make sense to add regression tests for the boundary cases, e.g. INTEGER, NUMBER(9,0), NUMBER(10,0), and NUMBER(20,0)? Maybe we can also consider whether NUMBER(10..18,0) should map to BIGINT rather than DECIMAL.

[ylq5126]

I noticed the existing Oracle tests are failing after this change. Oracle INTEGER seems to be exposed by ojdbc as NUMBER(*,0) / NUMERIC with scale 0, and its reported precision may not match precision <= 9, so it now falls through to DECIMAL. That changes resultSet.getObject() from an integer-like value to BigDecimal(1), causing the assertions in OracleStatementSuite to fail.

Would it make sense to add regression tests for the boundary cases, e.g. INTEGER, NUMBER(9,0), NUMBER(10,0), and NUMBER(20,0)? Maybe we can also consider whether NUMBER(10..18,0) should map to BIGINT rather than DECIMAL.

I will create a new merge request later.