Miguel Angel Prada <mprada@hoplasoftware.com> writes:
> I would need help to know what could be happening to cause the error
> when using the /date_trunc/ function.
EXPLAIN would be informative, but I bet what is happening is that the
date_trunc condition is being pushed down to the scan of pg_class,
since it mentions no variables that aren't available there. Then it
can get evaluated on tables whose names don't match the pattern you
expect. I doubt it's more than luck that PG 15 isn't doing the
same thing.
The usual recommendation for fixing this kind of thing is to insert an
optimization fence to keep the WHERE clause from being pushed down.
You could add "OFFSET 0" in the sub-select, or convert it into a
materialized CTE.
regards, tom lane
