> On Apr 8, 2026, at 09:46, David G. Johnston <[email protected]>
> wrote:
>
> On Tuesday, April 7, 2026, Chao Li <[email protected]> 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/
