Horton
Menu

Re: updates for handling optional argument in system functions

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
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>
Date: 2026-04-08T01:46:17Z
Lists: pgsql-hackers 
On Tuesday, April 7, 2026, Chao Li <li.evan.chao@gmail.com> wrote:

>
> We can clearly see ":expr {FUNCEXPR :funcid 1573 “.
>
> 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=1573 and produces a textual SQL representation, which
is then executed during pg_restore.  This happens manually, and also
automatically by pg_upgrade.  Since the text form hasn’t changed the 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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Simplify creation of built-in functions with default arguments.