Re: BUG #19784: "no relation entry for relid 1" when costing = ANY (<array expr over max(col)>) in a MinMaxAggPath

shihao zhong <zhong950419(at)gmail(dot)com> writes:
>> It does not fix this:

>> CREATE TABLE ei (a int4[]);
>> CREATE INDEX ON ei
>> ((((1 = ANY (a))::int + (2 = ANY (a))::int) <@ int4range(0, 5)));
>> SELECT * FROM ei;
>> ERROR: no relation entry for relid 1

BTW, I wondered when that failure started, and found that
git bisect pins it on

c925ad30b047ec1388247539e86729d584c34b8d is the first bad commit
commit c925ad30b047ec1388247539e86729d584c34b8d
Author: Richard Guo <rguo(at)postgresql(dot)org>
Date: Tue Dec 9 16:56:26 2025 +0900

Fix const-simplification for index expressions and predicate
...
Because we need to cache the const-simplified index expressions and
predicate in the relcache entry, we cannot fix the Vars before
applying eval_const_expressions. To ensure proper reduction of
NullTest clauses, this patch runs eval_const_expressions a second time
-- after the Vars have been fixed and with a valid root.

So I'm thinking there is a problem here. This commit appears
to be supposing that it's accomplishing something by running
eval_const_expressions with baserel data available -- but as this
failure shows, the baserel data *isn't* available yet. So even
with a fix that prevents examine_variable from failing, it seems
likely that we are not managing to reduce index expressions the
same as we will reduce query expressions later.

Not very sure what to do about that. Maybe index expressions
have to be loaded in a second pass after we've set up baserel data?
Maybe the idea of caching them in relcache has to be abandoned
(or at least we have to rethink whether we can cache an eval'd
form of them)?

regards, tom lane