Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Date
Msg-id 765959.1729216005@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault  (Tender Wang <tndrwang@gmail.com>)
List 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 by date:

Previous
From: Tender Wang
Date:
Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Next
From: Amit Langote
Date:
Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault