Re: EXEC_EVALDEBUG debugging broken?

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: EXEC_EVALDEBUG debugging broken?
Дата
Msg-id
10933.1185294356@sss.pgh.pa.us
Ответ на
Re: EXEC_EVALDEBUG debugging broken? (peter.trautmeier@gmx.de)
Список
Дерево обсуждения
EXEC_EVALDEBUG debugging broken? peter.trautmeier@gmx.de
Re: EXEC_EVALDEBUG debugging broken? Tom Lane <tgl@sss.pgh.pa.us>
Re: EXEC_EVALDEBUG debugging broken? peter.trautmeier@gmx.de
Re: EXEC_EVALDEBUG debugging broken? Tom Lane <tgl@sss.pgh.pa.us>
Re: EXEC_EVALDEBUG debugging broken? peter.trautmeier@gmx.de
Re: EXEC_EVALDEBUG debugging broken? Tom Lane <tgl@sss.pgh.pa.us>
peter.trautmeier@gmx.de 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 that time?

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.

The problem is that outfuncs.c knows about all the Expr node types and
none of the ExprState types, there being no need to dump the latter in
normal use.  There is a valid argument that we ought to support dumping
PlanState and ExprState trees for debugging purposes, but it just seems
like more maintenance effort than it's worth ...

> (Is there a way do get this type info with gdb's help?)

"p *(Node *) ptr" ought to do it.
		regards, tom lane

В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата:
От: peter.trautmeier@gmx.de
Дата:
FAQ