On Wed, 25 Mar 2026 at 22:51, David Rowley <[email protected]> wrote: > > On Thu, 26 Mar 2026 at 10:25, Matthias van de Meent > <[email protected]> wrote: > > I'm happy to mark this function as STABLE for now (to prevent its > > inclusion in permanent storage), and/or to adjust the code to adjust > > for subnormal inputs (values with incorrect/inconsistent/unexpected > > sign extensions). > > You lost me at this part. How does marking the function as STABLE > prevent users from persisting things on disk based on the return value > of the function? I expected the primary use case for this would be in > trigger functions that make decisions about data that goes into > tables.
Indexes and stored generated columns' expression may only contain IMMUTABLE functions, so that they don't change output when the inputs values are unchanged. As the current datum_image_equal depends on the volatile contents/definition of sign-extended bytes (which we clearly don't have a defined/expected value for) that makes the output of this function not immutable for the "same" input values. Marking it as STABLE would therefore prevent its values from being stored inside PostgreSQL's definitions and storing the wrong value (or making a decision based on the wrong value, in case of partial indexes). That wouldn't solve the issue when used in a trigger function, indeed; which is why the second part shows that pg_datum_image_equal could itself check and adjust byval types to have consistent sign-extended bytes before passing them on to datum_image_equal, so that it won't be sensitive to the issue discussed in the memoization thread. Kind regards, Matthias van de Meent
