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

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> A query whose aggregates are all min()/max() over an indexed column
> fails in the planner with an internal error when its target list or
> HAVING contains "x op ANY/ALL (array)" where the array is an expression
> over the aggregate (anything but a constant or a plain ARRAY[...]):

> CREATE TABLE rt (c0 int4);
> CREATE INDEX ON rt (c0);
> SELECT 1 = ANY (array_append(ARRAY[2], max(c0))) FROM rt;
> ERROR: no relation entry for relid 1

Thanks for the report!

> As far as I can tell: grouping_planner() calls
> preprocess_minmax_aggregates() before query_planner().

Yeah. Potential alternatives are

(1) Restructure things enough to do that in some other order.
Not clear if this is feasible at all, and for sure not something
I'd want to back-patch if at all possible.

(2) Modify estimate_array_length() to not try to access baserel
data in this situation.

It's not very hard to do (2), for example as attached. What is
bothering me a bit here is that this is surely not the only
estimator routine that calls examine_variable, so why don't we
have other problems?

I'm also wondering if we couldn't adapt this to get rid of the
ugly kluge that 77d0e82e5 added (hence cc'ing Richard). Tracing
through that example, I see that the query level with setOperations
does have a simple_rel_array set up when we reach this, so the
attached isn't enough to fix it as-is. But we could test something
else that a setOperations query doesn't fill, such as all_baserels.

A different line of attack could be to modify examine_variable
so it doesn't fail on a Var that has no baserel data available.
That's a little sad in that it could easily mask bugs that we'd
like to know about; but it would feel less like a band-aid.

regards, tom lane