Re: GREATEST/LEAST ignores comparison operator volatility in contain_volatile_functions_walker

Mats Rydberg <mats(at)planetscale(dot)com> writes:
> GREATEST and LEAST (MinMaxExpr nodes) are missing from
> contain_volatile_functions_walker in src/backend/optimizer/util/clauses.c.
> OpExpr nodes are correctly handled -- the walker resolves the oprcode via
> set_opfuncid and checks func_volatile. But there is no MinMaxExpr case, so
> GREATEST/LEAST always appears function-free to the volatility checker
> regardless of the < or > operator's provolatile.

This is intentional, per the comment in
contain_mutable_functions_walker (which
contain_volatile_functions_walker refers to):

* It should be safe to treat MinMaxExpr as immutable, because it will
* depend on a non-cross-type btree comparison function, and those should
* always be immutable.

A non-cross-type btree comparison function directly determines the
ordering of an index for its data type, so if it isn't immutable then
you can't rely on the index to be consistent.

> The practical consequence: a GREATEST/LEAST expression whose comparison
> operator is STABLE or VOLATILE is incorrectly treated as IMMUTABLE. The
> reproducer below demonstrates this via a generated column, which requires
> an IMMUTABLE expression. PostgreSQL accepts the column definition when it
> should reject it.

This reproducer depends on an invalid operator class. The reason
why you can't make an operator class without superuser privilege
is that the system depends on them behaving per spec. We'd try
to enforce that rather than just assume it, were it not for the
halting problem.

regards, tom lane