Re: eclg -C ORACLE breaks data
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-04-17T08:00:59Z
Lists: pgsql-hackers
On Mon, Apr 10, 2023 at 05:35:00PM +0900, Kyotaro Horiguchi wrote: > This results in overwriting str[-1], the last byte of the preceding > numeric in this case, with 0x00, representing the digit '0'. When > callers of ecpg_get_data() explicitly pass zero as varcharsize, they > provide storage that precisely fitting the data. Good find, that's clearly wrong. The test case is interesting. On HEAD, the processing of the second field eats up the data of the first field. > However, it remains > uncertain if this assumption is valid when ecpg_store_result() passes > var->varcharsize which is also zero. Consequently, the current fix > presumes exact-fit storage when varcharsize is zero. Based on what I can read in sqlda.c (ecpg_set_compat_sqlda() and ecpg_set_native_sqlda()), the data length calculated adds an extra byte to the data length when storing the data references in sqldata. execute.c and ecpg_store_result() is actually much trickier than that (see particularly the part where the code does an "allocate memory for NULL pointers", where varcharsize could also be 0), still I agree that this assumption should be OK. The code is as it is for many years, with its logic to do an estimation of allocation first, and then read the data at once in the whole area allocated.. This thinko has been introduced by 3b7ab43, so this needs to go down to v11. I'll see to that. -- Michael
Commits
-
ecpg: Fix handling of strings in ORACLE compat code with SQLDA
- 9eb44bb043af 11.20 landed
- a28bd77136db 12.15 landed
- e9e457d22d26 13.11 landed
- 02f0764546a9 14.8 landed
- 8c746be44002 15.3 landed
- f18029084784 16.0 landed