Matthias van de Meent <[email protected]> writes:
> On Wed, 25 Mar 2026 at 22:51, David Rowley <[email protected]> wrote:
>> 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.
This seems to me to be a rather creative misinterpretation of what
STABLE and IMMUTABLE mean. If you want to claim that IMMUTABLE means
that, then the function isn't STABLE either, since it could give
different results for the "same" input values within one query.
Moreover, switching from IMMUTABLE to STABLE wouldn't fix the
problem of users assuming more than they should.
The actual problem here is that datum_image_eq is assuming more
than it should about the contents of a pass-by-value Datum.
That was okay for its original use-cases because a false not-equal
report would just end in not applying some optimization. But
Memoize thinks that the answers are exact, and users would too
if we expose the function at SQL level.
I think what David proposed at
<caaphdvref-uiqbahtrtqwq6z1x9snstjw+dfb2du5gob-up...@mail.gmail.com>
is not a hack, but in fact correcting datum_image_eq/datum_image_hash
to not assume that unspecified bits are reliably the same.
regards, tom lane
