pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tender Wang <tndrwang@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
Date: Thu, 17 Oct 2024 21:46:45 -0400
Message-ID: <765959.1729216005@sss.pgh.pa.us> (raw)
In-Reply-To: <CAHewXNkcG=adJtfqHXuLnZrDAfSWPrX0GwLU98hYLjJbgZON1A@mail.gmail.com>
References: <18657-1b90ccce2b16bdb8@postgresql.org>
	<Zw8Gk3xtrSmQh9mD@paquier.xyz>
	<CA+HiwqFpzUYXOqcJ4LdAoLjAxDJ-e4-mVe=4z9-jC5vhV0ZwEg@mail.gmail.com>
	<CAHewXNmSvzsSqqf6fG7OEkmB2aUuCa7SM4pfVrs9vBeCWZu7yQ@mail.gmail.com>
	<CA+HiwqGDZMwi6O9w64vtd0fFTeow4GnKfWraSaJFxC-y7mCm+w@mail.gmail.com>
	<CAHewXN=hHQepA9-JHaW9z-orPE-qA2UEFNvAvLpYZr6e1PGq2Q@mail.gmail.com>
	<CA+HiwqF0iihKd28ycs5BJcYprAWUBDqHv03vqLMteBid2YDCyA@mail.gmail.com>
	<CAHewXNnc35-OX=wA+MHkj+asYa0oezLwV5by=D00ga+EawN7Fg@mail.gmail.com>
	<CA+HiwqGJUv2Y=qCRO1kL-6cfZ79zAgag_zJ_=U4q-RaNUv9r2g@mail.gmail.com>
	<71060.1729088799@sss.pgh.pa.us>
	<CA+HiwqGZV2YWvso8B4bpPAEJDuEhDos3oUTxDTfr9kpX=nOAgA@mail.gmail.com>
	<508107.1729126612@sss.pgh.pa.us>
	<569213.1729138329@sss.pgh.pa.us>
	<CA+HiwqHpU4VARMpEih6O5xd+psvODEzutf8Rkx7m+sU8OPV-bA@mail.gmail.com>
	<711200.1729197017@sss.pgh.pa.us>
	<CAHewXNkcG=adJtfqHXuLnZrDAfSWPrX0GwLU98hYLjJbgZON1A@mail.gmail.com>

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





view thread (31+ messages)  latest in thread

Message-ID: <765959.1729216005@sss.pgh.pa.us>
Permalink:  ../765959.1729216005@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/765959.1729216005@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, tndrwang@gmail.com, amitlangote09@gmail.com, michael@paquier.xyz, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault
  In-Reply-To: <765959.1729216005@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox