From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | ECPG deccall3 functions vs. risnull() inputs |
Date: | 2025-01-06 19:27:48 |
Message-ID: | 20250106192748.cf.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
When I compiled with -ftrivial-auto-var-init=pattern, ECPG's dec_test reported
a diff. Nothing else reported a diff. dec_test calls informix.c numeric
functions like decadd() and decmul(). One test operand, decarr[14], is
risnull(). When these informix.c functions get an risnull() input, they just
return 0 without changing the output parameter. Our ecpg.sgml docs don't
discuss this. Applicable Informix doc
https://www.ibm.com/docs/en/informix-servers/15.0.0?topic=information-null-values-in-host-variables
just says "do not attempt to perform arithmetic", which I take to assign
undefined behavior for risnull() input. If someone can easily check how
Informix works for this, would you do so?
Before commit 757fb0e (2004-03), these functions would rsetnull() the output
parameter if given risnull() input. That's like the effect of SQL NULL input
to a SQL arithmetic operator. I suspect the change for risnull() input was an
unintentional side effect of that commit's mission to make dec*() functions
support callers passing the same var as both an input and an output.
Two patches attached. The first patch just makes the test clarify what's
happening. The second would restore the pre-2004 behavior, but I plan to
commit that one only if someone's Informix testing confirms it.
Attachment | Content-Type | Size |
---|---|---|
test-deccall3-null-v1.patch | text/plain | 11.9 KB |
deccall3-null-v1.patch | text/plain | 11.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-01-06 19:32:16 | Re: Parametrization minimum password lenght |
Previous Message | Nathan Bossart | 2025-01-06 19:20:13 | Re: Proposal: add new API to stringinfo |