Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
От | Tom Lane |
---|---|
Тема | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault |
Дата | |
Msg-id | 765959.1729216005@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault (Tender Wang <tndrwang@gmail.com>) |
Список | pgsql-bugs |
Tender Wang <tndrwang@gmail.com> writes: >> In any case, whatever we do in master, you can't "simply revert" >> b6e1157e7 in released branches. It changed the way JsonValueExpr is >> represented in stored rules, and you don't get to undo that midstream. > Sorry, I can't fully understand what you said above. What's the stored > rule? > And "you don't get to undo that midstream." What is the Scenario that we > get to undo? If somebody has created a view that contains a JsonValueExpr, then the post-parse-analysis query tree for that is stored in pg_rewrite. A minor version update can't change that query tree. So basically, once a major version has shipped, its parse-analysis output format is frozen. We can redefine that sort of thing in major releases, because either pg_upgrade or dump/reload will result in re-parsing view definitions. But that doesn't happen in minor-version updates. This restriction doesn't apply to planner output trees, since those don't have any lifespan longer than a session. That's how come it's okay to consider changing the behavior of eval_const_expressions. regards, tom lane
В списке pgsql-bugs по дате отправления: