Re: updates for handling optional argument in system functions

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>
To: "David G. Johnston" <david.g.johnston@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-08T02:09:51Z
Lists: pgsql-hackers

> On Apr 8, 2026, at 09:46, David G. Johnston <david.g.johnston@gmail.com> wrote:
> 
> 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.
> 

Hi David, thanks for the explanation, I really didn’t know that.

Then, the patch looks good to me. GET_PRETTY_FLAGS(false) returns PRETTYFLAG_INDENT, so no behavior change either.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







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.