Re: Potential issue in ecpg-informix decimal converting functions
Aidar Imamov <a.imamov@postgrespro.ru>
From: a.imamov@postgrespro.ru
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>
Date: 2024-03-06T19:12:46Z
Lists: pgsql-hackers
Daniel Gustafsson писал(а) 2024-03-06 18:03: >> On 27 Feb 2024, at 06:08, Michael Paquier <michael@paquier.xyz> wrote: >> >> On Mon, Feb 26, 2024 at 12:28:51AM +0100, Daniel Gustafsson wrote: >>> Yeah, I think this is for HEAD only, especially given the lack of >>> complaints >>> against backbranches. >> >> Daniel, are you planning to look at that? I haven't done any detailed >> lookup, but would be happy to do so it that helps. > > I had a look at this today and opted for trimming back the patch a bit. > Reading the informix docs the functions we are mimicking for > compatibility here > does not have an underflow returnvalue, so adding one doesn't seem > right (or > helpful). The attached fixes the return of overflow and leaves it at > that, > which makes it possible to backpatch since it's fixing the code to > match the > documented behavior. > > -- > Daniel Gustafsson I agree with the proposed changes in favor of backward compatibility. Also, is it a big deal that the PGTYPESnumeric_to_long() function doesn't exactly match the documentation, compared to PGTYPESnumeric_to_int()? It handles underflow case separately and sets errno to PGTYPES_NUM_UNDERFLOW additionally.
Commits
-
doc: Document error handling in PGTYPESnumeric_to_long
- 68174679fea2 17.0 landed
-
ecpg: Fix return code for overflow in numeric conversion
- b2d6b4c728a2 17.0 landed