Re: A modest proposal: make parser/rewriter/planner inputs read-only

Поиск
Список
Период
Сортировка
От Richard Guo
Тема Re: A modest proposal: make parser/rewriter/planner inputs read-only
Дата
Msg-id CAMbWs4_9ozYZi4_s8DqVKDtOmYTmeRgQ0pZcZh1b4+3VxD8XXQ@mail.gmail.com
обсуждение исходный текст
Ответ на A modest proposal: make parser/rewriter/planner inputs read-only  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: A modest proposal: make parser/rewriter/planner inputs read-only
Список pgsql-hackers
On Sun, Apr 6, 2025 at 1:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The parser, rewriter, and planner all have a bad habit of scribbling
> on their input parsetrees.  At this point I've lost count of how many
> bugs that's caused (but e33f2335a and 0f43083d1 are the two latest
> examples), and of how many places there are that are brute-forcing a
> solution to the problem by copying a whole parsetree before letting
> one of these subsystems see it.
>
> Years ago we fixed the executor to treat its input Plan trees as
> read-only.  It seems like we really ought to do the same for these
> upstream subsystems.  Surely, whatever benefit we get from changing
> Node contents in-place is lost due to all these other hacks.

While I'm in favor of this idea, it seems that it will require lots of
code changes.  In particular, within the planner, the parsetree goes
through considerable transformations during the preprocessing phase,
such as subquery pull-up, constant folding, and so on.  Would this
proposal mean we'd need to refactor all those places to treat the
input parsetrees as read-only?  Just trying to understand the scope of
what would be involved.

Thanks
Richard



В списке pgsql-hackers по дате отправления: