Leave length/indicator untouched on out-of-range overflow (follow-up to #210)

[davecramer]

Follow-up to #210 (merged), addressing the review note on that PR: on the out-of-range SQL_ERROR path the data buffer is left untouched, but the length/indicator was still set to the C type's size (4 or 2).

This skips the length/indicator write when the conversion overflows (result == COPY_RESULT_OVERFLOW), for symmetry with the untouched data buffer. Within spec either way (buffer and indicator are undefined after SQL_ERROR).

Verified on PostgreSQL 18: int-overflow and result-conversions tests still pass; error rows no longer report the C-type size in the indicator.

[singhpratech]

Verified the follow-up on its merge commit (d747b18) side by side with #210's (4a5a0e7), both built from a fresh clone in a clean Ubuntu 24.04 container against libpq 16.15 and unixODBC 2.3.12, running the program from #207 extended with the SQLBindCol + SQLFetch path and with every buffer pre-set (data 12345, indicator -99) against PostgreSQL 16.15:

rows	#210 (4a5a0e7)	#211 (d747b18)
out-of-range (int8 → SQL_C_SLONG/SQL_C_SSHORT, int4 → SQL_C_SSHORT), both paths	rc=-1, 22003, data 12345, indicator = C-type size (4 or 2)	rc=-1, 22003, data 12345, indicator = 0
in-range rows and SQL_C_SBIGINT, both paths	unchanged	unchanged

So the C-type size is gone from the indicator on the error rows, on SQLGetData and SQLBindCol alike, and nothing that fits has moved. One detail for the record: the indicator reads 0 rather than the caller's -99, because copy_and_convert_field() writes *pIndicatorBindRow = 0 in its prologue (convert.c, just after the LENADDR_SHIFT lines) and PGAPI_GetData passes the same pcbValue pointer as both pcbValue and pIndicator, so that early write lands in the caller's indicator before the conversion runs. Within spec either way, as you said; only mentioning it so "untouched" in the commit message is read as "no longer the C-type size". If you ever want it literally untouched, moving that prologue write behind the overflow check would do it, but I would not spend a release on it.

The driver these two reports came out of, adbcBridge, reads int8 columns as SQL_C_SBIGINT and so never wrapped a value itself; its upstream tracker now records #210 and #211 as fixed, pending a tagged release. Thank you for picking up a one-line aside in a results comment and turning it into a merged follow-up within four days. That is a level of care that makes reporting against psqlodbc a pleasure.