You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix DECFLOAT conversion for fetch APIs (#1075) - #1076
The issue was caused by allocating the bound-column buffer based on the column display size. In some cases, the display size was insufficient for the DECFLOAT string representation generated by the CLI conversion routines, resulting in fetch failures.
Fix:
Use MAX_DECFLOAT_LENGTH to allocate sufficient buffer space for DECFLOAT values.
Ensure adequate space for DECFLOAT value conversion during fetch operations.
Prevent fetch failures when DECFLOAT values have longer string representations.
Root cause fix is correct.MAX_DECFLOAT_LENGTH (44) is an existing constant already proven correct elsewhere in ibm_db.c:14488 for SQLGetData-based DECFLOAT fetches (sign + 34 digits + decimal point + E + exponent sign + up to 4 exponent digits + NUL ≈ 43). Using it consistently for the SQLBindCol paths too directly addresses issue CLI0111E on fetch of ordinary DECFLOAT values: bound-column buffer sized from precision+3, not display size #1075 (CLI0111E, buffer sized from precision+3 instead of true display length).
Both allocation sites relevant to fetch (bind_column_helper for single-row fetch, bind_rowset_columns for rowset/bulk fetch) are covered. Other SQL_DECFLOAT references in the file (ibm_db.c:2758, ibm_db.c:15358) only consume/convert/free the already-bound buffer, so they don't need parallel changes.
No duplicate case labels introduced — compiles fine logically.
Adds a test exercising boundary-ish DECFLOAT string values (small magnitude, trailing zeros, negative).
Issues to fix before merging
Missing/incomplete expected-output update — will break z/OS native test runs.testfunctions.py's assert_expect routes z/OS native runs (platform.system() == 'z/OS'/'OS/390' and test name in the testCasesIn allowlist, which explicitly includes test_decfloat) to expected_ZOS_ODBC(). That function uses the __ZOS_ODBC_EXPECTED__ block verbatim if present in the file — it does not fall back to __ZOS_EXPECTED__ in that case. The PR only added the 3 new expected lines to the __LUW_EXPECTED__ and __ZOS_EXPECTED__ blocks in test_decfloat.py, but left __ZOS_ODBC_EXPECTED__ unchanged. Since the new test code runs on that config too (DBMS_NAME there won't start with IDS), the captured output will include the 3 new lines while the expected block won't — causing an assertion failure on z/OS native CI/test runs.
Fix: add the same 3 lines (#0.005202572, #0.00520257200000000, #-0.001234567890123456) to the __ZOS_ODBC_EXPECTED__ block as well.
__IDS_EXPECTED__ and __SYSTEMI_EXPECTED__ are correctly left alone (IDS is explicitly skipped by the new if serverinfo.DBMS_NAME[0:3] != 'IDS' guard, and SYSTEMI's whole expected block is #NA, implying the test doesn't run there at all).
Minor: code duplication. The new SQL_DECFLOAT block in _python_ibm_db_bind_column_helper (~25 lines) is a near-exact copy of the SQL_BIGINT block, differing only in the in_length computation. Not a blocker, but could be simplified by computing in_length per-type first and sharing the alloc/bind/log logic, reducing future maintenance risk (e.g., if the bind-column logic changes, it now must change in two places).
Verdict
Do not merge yet. The C-side fix itself looks correct and safe (reuses a well-established constant, properly scoped to the two buggy allocation sites). However, the test update has a real gap: the __ZOS_ODBC_EXPECTED__ block wasn't updated, which will cause test_decfloat to fail on z/OS native test runs. Ask the author to add the matching 3 lines to that block (and ideally run/verify the z/OS-ODBC test path) before merging.
Fix DECFLOAT bound-column buffer size and z/OS ODBC expectations
Use MAX_DECFLOAT_LENGTH consistently for SQL_DECFLOAT columns bound via
SQLBindCol in _python_ibm_db_bind_column_helper. Merge the SQL_BIGINT and
SQL_DECFLOAT cases to compute in_length based on the column type while
sharing the allocation, binding, and logging logic.
Add the missing DECFLOAT boundary-value expected output lines to the ZOS_ODBC_EXPECTED block in test_decfloat.py so the new assertions
match on z/OS native ODBC test runs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix DECFLOAT bound-column buffer allocation
The issue was caused by allocating the bound-column buffer based on the column display size. In some cases, the display size was insufficient for the DECFLOAT string representation generated by the CLI conversion routines, resulting in fetch failures.
Fix:
MAX_DECFLOAT_LENGTHto allocate sufficient buffer space for DECFLOAT values.