> On 6 Mar 2024, at 20:12, a.ima...@postgrespro.ru wrote:
> I agree with the proposed changes in favor of backward compatibility.
I went ahead to pushed this after another look. I'm a bit hesitant to
backpatch this since there are no reports against it, and I don't have good
sense for how ECPG c
Daniel Gustafsson писал(а) 2024-03-06 18:03:
On 27 Feb 2024, at 06:08, Michael Paquier 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 loo
> On 27 Feb 2024, at 06:08, Michael Paquier 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 det
Michael Paquier писал(а) 2024-02-28 02:14:
On Tue, Feb 27, 2024 at 09:24:25AM +0100, Daniel Gustafsson wrote:
I have it on my TODO for the upcoming CF.
Okay, thanks.
--
Michael
Greetings!
Sorry, I had been waiting for a few days for my cool-off period to end.
The patch now is registered to
On Tue, Feb 27, 2024 at 09:24:25AM +0100, Daniel Gustafsson wrote:
> I have it on my TODO for the upcoming CF.
Okay, thanks.
--
Michael
signature.asc
Description: PGP signature
> On 27 Feb 2024, at 06:08, Michael Paquier 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 det
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.
--
Mic
> On 24 Feb 2024, at 02:15, Michael Paquier wrote:
>
> On Fri, Feb 23, 2024 at 06:03:41PM +0300, a.ima...@postgrespro.ru wrote:
>> Thank's for advice, the patch will be registered for the next commitfest.
>
> The risk looks really minimal to me, but playing with error codes
> while the logic of
On Fri, Feb 23, 2024 at 06:03:41PM +0300, a.ima...@postgrespro.ru wrote:
> Thank's for advice, the patch will be registered for the next commitfest.
The risk looks really minimal to me, but playing with error codes
while the logic of the function is unchanged does not strike me as
something to bac
Daniel Gustafsson писал(а) 2024-02-23 13:44:
On 22 Feb 2024, at 17:54, a.ima...@postgrespro.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 decto
> On 22 Feb 2024, at 17:54, a.ima...@postgrespro.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_
Hi, everyone!
I found a potential bug in dectoint() and dectolong() functions from
informix.c. "Informix Compatibility Mode" doc chapter says that
ECPG_INFORMIX_NUM_OVERFLOW is returned if an overflow occurred. But
check this line in dectoint() or dectolong() (it is present in both):
if (ret == P
12 matches
Mail list logo
