Conversation
There was a problem hiding this comment.
Pull request overview
Updates the Postgres connector’s type parsing to support a new DECIMAL/NUMERIC field (e.g., the test_decimal field mentioned in the PR title) by customizing how values are returned from pg.
Changes:
- Added a
pgOID 1700 (NUMERIC/DECIMAL) type parser in the Postgres connector.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // which treats them as LOCAL server time. Return raw strings so getFieldValue can parse as UTC. | ||
| types.setTypeParser(1114, (val) => val); // TIMESTAMP WITHOUT TIME ZONE | ||
| types.setTypeParser(1082, (val) => val); // DATE | ||
| types.setTypeParser(1700, (val) => val === null ? null : parseFloat(val).toString()); // NUMERIC/DECIMAL |
There was a problem hiding this comment.
The NUMERIC/DECIMAL type parser uses parseFloat(val).toString(), which will lose precision for many valid Postgres NUMERIC values (and also strips trailing zeros, potentially changing the intended scale, e.g. '1.00' -> '1'). Since this connector already models DECIMAL separately (AdminForthDataTypes.DECIMAL) and pg returns NUMERIC as a string by default, consider returning the raw string (like the timestamp/date parsers) or using a decimal library / scale-aware formatting if numeric normalization is required.
| types.setTypeParser(1700, (val) => val === null ? null : parseFloat(val).toString()); // NUMERIC/DECIMAL | |
| // Preserve exact NUMERIC/DECIMAL values as returned by pg to avoid precision and scale loss. | |
| types.setTypeParser(1700, (val) => val); // NUMERIC/DECIMAL |
There was a problem hiding this comment.
I think we have to search another approach
kulikp1
changed the title
No description provided.