Fix hypothetical bug in ExprState building for hashing
authorDavid Rowley
Tue, 5 Nov 2024 20:16:00 +0000 (09:16 +1300)
committerDavid Rowley
Tue, 5 Nov 2024 20:16:00 +0000 (09:16 +1300)
commit87f81a55632107006e5006a2d0bc5272ebaeca64
tree043d6d39f4ba0121ba4363a4277a891480b52d84
parent7bdaa4b54208afe0d0fc691877da920016db6987
Fix hypothetical bug in ExprState building for hashing

adf97c156 gave ExprStates the ability to hash expressions and return a
single hash value.  That commit supports seeding the hash value with an
initial value to have that blended into the final hash value.

Here we fix a hypothetical bug where if there are zero expressions to
hash, the initial value is stored in the wrong location.  The existing
code stored the initial value in an intermediate location expecting that
when the expressions were hashed that those steps would store the final
hash value in the ExprState.resvalue field.  However, that wouldn't happen
when there are zero expressions to hash.  The correct thing to do instead
is to have a special case for zero expressions and when we hit that case,
store the initial value directly in the ExprState.resvalue.  The reason
that this is a hypothetical bug is that no code currently calls
ExecBuildHash32Expr passing a non-zero initial value.

Discussion: https://postgr.es/m/CAApHDvpMAL_zxbMRr1LOex3O7Y7R7ZN2i8iUFLQhqQiJMAg3qw@mail.gmail.com
src/backend/executor/execExpr.c