Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> On Tue, Apr 21, 2026 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * I'm inclined to think that pretty much all the mucking with
>> opclasses is misplaced too: those structures are not immutable
>> either. All of that should move to rewriting, planning, or
>> even executor startup.
> Thanks for this feedback! I will work on a patch to move those checks
> to different phases, and also guard against FDW partitions.
Actually, on second thought that part might be okay. It's not so
different from things we do elsewhere in the parser, such as pick a
suitable equality operator for an IN clause. Even though you could
argue that those decisions ought to be postponed till we're ready to
execute the statement, it's not so bad because what the construct
actually ends up depending on is a specific operator or function.
Even if the user later changes the operator class that we used to find
that function, its semantics are presumably still fit for purpose,
or close enough.
I definitely don't like checking volatility at parse time, though.
(BTW, to be clear: the situation of concern here is where we parse a
query and put it into a rule or new-style SQL function or the like.
By the time we get to executing that parse tree, much might have
changed. Anything we expect to still be there had better be recorded
as a dependency of the parsetree. Even then, the dependency only
guarantees existence of the object, not that its properties didn't
change.)
regards, tom lane
