From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tender Wang <tndrwang(at)gmail(dot)com> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault |
Date: | 2024-10-18 01:46:45 |
Message-ID: | 765959.1729216005@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tender Wang <tndrwang(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2024-10-18 02:04:05 | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault |
Previous Message | Tender Wang | 2024-10-18 01:34:33 | Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault |