From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | a(dot)imamov(at)postgrespro(dot)ru |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Potential issue in ecpg-informix decimal converting functions |
Date: | 2024-02-23 10:44:24 |
Message-ID: | 28064113-68CD-4C6E-BB6B-5E70C640F7D7@yesql.se |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 22 Feb 2024, at 17:54, a(dot)imamov(at)postgrespro(dot)ru wrote:
> PGTYPESnumeric_to_int() and PGTYPESnumeric_to_long()
> functions return only 0 or -1. So ECPG_INFORMIX_NUM_OVERFLOW can never
> be returned.
Indeed, this looks like an oversight.
> I think dectoint(), dectolong() and PGTYPESnumeric_to_int() functions
> should be a little bit different like in proposing patch.
> What do you think?
- Convert a variable to type decimal to an integer.
+ Convert a variable of type decimal to an integer.
While related, this should be committed and backpatched regardless.
+ int errnum = 0;
Stylistic nit, we typically don't initialize a variable which cannot be
accessed before being set.
Overall the patch looks sane, please register it for the next commitfest to
make it's not missed.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-02-23 11:02:23 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Daniel Gustafsson | 2024-02-23 10:30:19 | Refactor SASL exchange in preparation for OAuth Bearer |