SEZ9 commented on issue #13022:
URL: https://github.com/apache/seatunnel/issues/13022#issuecomment-6513175469

   @SEPURI-SAI-KRISHNA thanks for tracing this through, that answers my 
question. Taking precision and scale from `COLUMN_SIZE` and `DECIMAL_DIGITS` of 
`DatabaseMetaData.getColumns` rather than from the stripped name is the right 
split: `normalizeTypeName` only picks the switch branch, and the actual 
`DecimalType` is built from what the driver reports. The table you ran against 
databend-jdbc 0.3.7 is what I wanted to see, so I'm satisfied the `DECIMAL` 
branch returns `DecimalType(10, 2)` and not a default.
   
   Two small follow-ups on this same point so the test keeps guarding it:
   
   1. Please add the `decimal(76, 10)` case from your table to 
`DatabendCatalogTest` alongside the existing `DecimalType(10, 2)` and 
`DecimalType(38, 0)` assertions. Since `DecimalType.equals` compares precision 
and scale, that locks in the wide-precision path too.
   2. Since the precision/scale values depend on the driver's `TYPE_NAME` 
parsing, a one-line comment near the `DECIMAL` branch noting that 
precision/scale come from `COLUMN_SIZE`/`DECIMAL_DIGITS` (not from the 
normalized name) would help the next reader.
   
   Nothing else from me on this topic; once those two are in on top of 
`8884fee49` I'm good here.
   
   <!-- streview-comment:2127 -->


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to