Re: [HACKERS] EXEC_EVALDEBUG debugging broken?

2007-07-25 Thread Tom Lane
[EMAIL PROTECTED] writes: > Is it possible to store the calculated logical value of certain > expressions, e.g. boolean OpExprs, in their ExprState on a per tuple > basis to reuse them later? (I guess I described some kind of > 'condition cache' here.) No ... what would be the point? If the expr

Re: [HACKERS] EXEC_EVALDEBUG debugging broken?

2007-07-25 Thread peter . trautmeier
Von: Tom Lane <[EMAIL PROTECTED]> > Yeah, exactly. ExecInitExpr builds an ExprState tree that mirrors the > structure of the Expr tree but contains all the run-time-variable data. > This tree is what's now being passed to ExecQual. I see, and ExecInitExpr wraps the OpExpr in an FuncExprState. I

Re: [HACKERS] EXEC_EVALDEBUG debugging broken?

2007-07-24 Thread Tom Lane
[EMAIL PROTECTED] writes: > Interesting, what do you mean by Plan trees are 'read only' now? Is it the > distinction between Plan trees and their corresponding PlanState nodes that > indicate the 'read only' behaviour and the 'writeable' state of the Plan, > respectively, that was introduced at

Re: [HACKERS] EXEC_EVALDEBUG debugging broken?

2007-07-24 Thread peter . trautmeier
Von: Tom Lane <[EMAIL PROTECTED]> > [EMAIL PROTECTED] writes: > > WARNING: could not dump unrecognized node type: 404 > > ExecQual: qual is ( > >{ > >} > > ) > > Yeah, that code is toast, we probably ought to remove it. It hasn't > worked since the changes to make the executor treat plan

Re: [HACKERS] EXEC_EVALDEBUG debugging broken?

2007-07-24 Thread Tom Lane
[EMAIL PROTECTED] writes: > WARNING: could not dump unrecognized node type: 404 > ExecQual: qual is ( >{ >} > ) Yeah, that code is toast, we probably ought to remove it. It hasn't worked since the changes to make the executor treat plan trees as read-only. Making it work would require t