| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Mark Wong <markwkm(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: updates for handling optional argument in system functions |
| Date: | 2026-04-08 01:46:17 |
| Message-ID: | CAKFQuwZ3QDK+kW+PQ1e00fXEgFasUUcLUrjgZJ4-OkKqb5D7yg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday, April 7, 2026, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-04-08 02:09:16 | Re: Automatically sizing the IO worker pool |
| Previous Message | jian he | 2026-04-08 01:45:50 | Re: using index to speedup add not null constraints to a table |