Hi,
On 2023-02-21 07:49:25 +0900, Michael Paquier wrote:
> On Sat, Feb 18, 2023 at 08:00:00AM +0000, PG Bug reporting form wrote:
> > By comparing two callstacks I can see that in the second case
> > ExecInterpExprStillValid() is executed after the latest
> > ExecEvalExprSwitchContext().
> > The ExecInterpExprStillValid() function contains:
> > /* skip the check during further executions */
> > state->evalfunc = (ExprStateEvalFunc) state->evalfunc_private;
> >
> > If just call evalfunc_private() here, the first case ends with the error as
> > expected.
>
> Yeah, it would sound logic to me to have consistency with the
> ExecEvalExprSwitchContext() checks here, so it seems like the executor
> has missed the call for a long time. Would you like to write a patch,
> perhaps? Did you bisect the origin of that?
What inconsistency / missed call? We use ExecInterpExprStillValid() on the
first execution, but not on later executions. I don't see cases where we omit
calls to ExecInterpExprStillValid().
Afaict this is a problem of a wrongly generated target list, which isn't what
ExecInterpExprStillValid() guards against:
/*
* First time through, check whether attribute matches Var. Might not be
* ok anymore, due to schema changes. We do that by setting up a callback
* that does checking on the first call, which then sets the evalfunc
* callback to the actual method of execution.
*/
state->evalfunc = ExecInterpExprStillValid;
Greetings,
Andres Freund