Re: updates for handling optional argument in system functions

From: Mark Wong <markwkm(at)gmail(dot)com>
To: Rui Zhao <zhaorui126(at)gmail(dot)com>
Cc: Tristan Partin <tristan(at)partin(dot)io>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: updates for handling optional argument in system functions
Date: 2026-10-14 20:46:33
Message-ID: as_qKfBTSplB89_P@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Sat, Sep 26, 2026 at 12:43:19AM +0800, Rui Zhao wrote:
> Hi Mark,
>
> I should have been clearer about points 1 and 2 in my last mail:
>
> > 1. Every existing call form behaves the same as before.
> >
> > 2. pg_upgrade from an unpatched cluster works for views over these
> > functions: afterwards the view trees reference pg_proc OIDs
> > 2504/2505/2506 instead of 1573/1640/1641, and the views return the
> > same rows as before the upgrade.
>
> Those were confirmations that existing calls and views still work.
> For the ACL failure later in point 2, I should have stated whether I
> thought it needed special handling.
>
> > Do I understand correctly that this is going to be considered an
> > unusual and rare occurrence? That we will expect the user to manually
> > handle the privileges instead of having pg_upgrade recognize that.
>
> Yes, I think manual handling is reasonable here. I manually restored
> the default privileges on pg_get_ruledef(oid) in the old cluster, then
> reran pg_upgrade to v10. The upgrade completed.
>
> > Am I misunderstanding?
>
> I meant this as a reminder for developers, especially C extension
> authors, when updating their code for the new major version. I'm not
> asking you to preserve compatibility with the old C calls.
>
> The macro changes will be caught when rebuilding, but an unchanged
> DirectFunctionCall2(pg_get_expr, ...) still compiles with v10 headers;
> I checked with -Werror. It needs the explicit third argument, just as
> decompile_conbin() now passes BoolGetDatum(false) in
> DirectFunctionCall3(). Recompiling alone doesn't fix that call.

Ah, understood now.

> One small comment remains: pg_get_indexdef() still says "In the extended
> version, there is a colno argument as well as pretty bool." There is
> only one version now, so that sentence could describe the arguments
> without the "extended version" distinction.

I've shortened that to now read:

There is a colno argument as well as an optional pretty bool.

I've attached a v10.1 series.

Thanks!

Regards,
Mark
--
Mark Wong
pgEdge: https://www.pgedge.com

Attachment Content-Type Size
v10.1-0001-Refactor-pg_get_ruledef-default-args-as-a-sing.patch text/plain 2.5 KB
v10.1-0002-Refactor-pg_get_viewdef-default-args-as-a-sing.patch text/plain 4.1 KB
v10.1-0003-Refactor-pg_get_indexdef-default-args-as-a-sin.patch text/plain 4.2 KB
v10.1-0004-Refactor-pg_get_constraintdef-default-args-as-.patch text/plain 2.8 KB
v10.1-0005-Refactor-pg_get_expr-default-args-as-a-single-.patch text/plain 3.6 KB
v10.1-0006-Refactor-pg_get_triggerdef-default-args-as-a-s.patch text/plain 2.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandre Felipe 2026-10-14 20:53:21 Fwd: [patch] bufmgr Half state CAS
Previous Message Tom Lane 2026-10-14 20:39:10 Re: Wrong results from self-join elimination with inheritance and ONLY