MIME-Version: 1.0
In-Reply-To: <576EE368-AFB1-4375-BB77-A04CE92CC2A4@gmail.com>
References: <aTiwu9o8vBkLreAL@ltdrgnflg2> <ac63G6p1LAdbsca0@ltdrgnflg2>
 <6de20662-36fd-4e00-a0b0-75d1e9deb5c8@proxel.se>
 <9e3ad0f4-c4ef-436b-a5a1-28f600d76a61@proxel.se>
 <adWWxf5YrHATATw3@ltdrgnflg2>
 <576EE368-AFB1-4375-BB77-A04CE92CC2A4@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Tue, 7 Apr 2026 18:46:17 -0700
Message-ID: 
 <CAKFQuwZ3QDK+kW+PQ1e00fXEgFasUUcLUrjgZJ4-OkKqb5D7yg@mail.gmail.com>
Subject: Re: updates for handling optional argument in system functions
To: Chao Li <li.evan.chao@gmail.com>
Cc: Mark Wong <markwkm@gmail.com>, Andreas Karlsson <andreas@proxel.se>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000f832b7064ee9107a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwZ3QDK%2BkW%2BPQ1e00fXEgFasUUcLUrjgZJ4-OkKqb5D7yg%40mail.gmail.com>
Precedence: bulk

--000000000000f832b7064ee9107a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 7, 2026, Chao Li <li.evan.chao@gmail.com> wrote:

>
> We can clearly see ":expr {FUNCEXPR :funcid 1573 =E2=80=9C.
>
> With this patch, will that view break? How would users find all such
> broken views? Maybe PostgreSQL already has some recommended way to handle
> this kind of situation that I am not aware of?
>

pg_dump resolves oid=3D1573 and produces a textual SQL representation, whic=
h
is then executed during pg_restore.  This happens manually, and also
automatically by pg_upgrade.  Since the text form hasn=E2=80=99t changed th=
e view
is still valid in v19.  You would see the new oid if inspecting the rule
after the upgrade.

So yes, the public serialization format being SQL and thus mandatory new
object creation during upgrade is the way PostgreSQL handles implementation
detail isolation.

David J.

--000000000000f832b7064ee9107a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, April 7, 2026, Chao Li &lt;<a href=3D"mailto:li.evan.chao@gmail=
.com">li.evan.chao@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><br>We can clearly see &quot;:expr {FUNCEXPR :funcid 1573 =E2=80=9C.<br>
<br>
With this patch, will that view break? How would users find all such broken=
 views? Maybe PostgreSQL already has some recommended way to handle this ki=
nd of situation that I am not aware of?<br>
</blockquote><div><br></div><div>pg_dump resolves oid=3D1573 and produces a=
 textual SQL representation, which is then executed during pg_restore.=C2=
=A0 This happens manually, and also automatically by pg_upgrade.=C2=A0 Sinc=
e the text form hasn=E2=80=99t changed the view is still valid in v19.=C2=
=A0 You would see the new oid if inspecting the rule after the upgrade.</di=
v><div><br></div><div>So yes, the public serialization format being SQL and=
 thus mandatory new object creation during upgrade is the way PostgreSQL ha=
ndles implementation detail isolation.</div><div><br></div><div>David J.</d=
iv><div><br></div>

--000000000000f832b7064ee9107a--