Re: updates for handling optional argument in system functions

From: Rui Zhao <zhaorui126(at)gmail(dot)com>
To: Mark Wong <markwkm(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-09-15 16:33:18
Message-ID: CAHWVJhH=D27jLa6cK_KCynikDu-h5bU29KfBBpUaNVLchwQ8Cg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Mark,

v9 applies cleanly on current master (f7700080dc4), and make check, the
TAP suites under src/bin and contrib check pass here. No objections to
the code; what follows is what I verified and a few small things.

1. Every existing call form behaves the same as before. I ran one
script against an unpatched build and a v9 build of the same base
commit: the one-, two- and three-argument calls of the six functions
(pg_get_viewdef by name, by oid and with wrap_column included, plus the
unknown-literal and NULL cases and the "is not unique" error for
pg_get_viewdef(oid, NULL)), pg_indexes/pg_rules/pg_views,
information_schema.columns and check_constraints, \d output and
schema-only pg_dump output are byte-identical between the two builds.
Views defined over the one-argument forms deparse identically as well:
the parser doesn't store default arguments in the FuncExpr, so
pg_get_viewdef of such a view still prints pg_get_viewdef(c.oid). What
is new is pg_get_indexdef(index, column) with just two arguments, and
named notation such as pg_get_viewdef(view => 'v', pretty => true).

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. For the case Fujii described, a GRANT on
pg_get_ruledef(oid) in the old cluster, pg_upgrade --check reports
"Clusters are compatible" and the upgrade then fails in the restore
step:

pg_restore: error: could not execute query: ERROR: function
pg_catalog.pg_get_ruledef(oid) does not exist
Command was: REVOKE ALL ON FUNCTION
"pg_catalog"."pg_get_ruledef"("oid") FROM PUBLIC;

pg_dump only emits ACLs for pg_catalog functions that differ from
pg_init_privs, so this needs someone to have changed the privileges of
one of the removed signatures.

3. Smaller things:

* The six commit subjects still say "in system_functions.sql"; since v4
the patches set proargdefaults in pg_proc.dat and don't touch
system_functions.sql.

* reformat_dat_file.pl moves descr back onto the "{ oid =>" line for
2505, 2506, 2507 and 2509 now that the descriptions are shorter. (It
also reformats uuid_larger/uuid_smaller, but that is pre-existing on
master.)

* func-info.sgml has pg_get_indexdef ( index oid [, column integer,
pretty boolean ] ); with the defaults, column can be given without
pretty, so [, column integer [, pretty boolean ] ] would describe it.

* For C callers: the _ext symbols go away and the fmgroids.h macros
lose their type suffixes (F_PG_GET_EXPR_PG_NODE_TREE_OID_BOOL becomes
F_PG_GET_EXPR). A DirectFunctionCall2(pg_get_expr, ...) in extension
code still compiles and then reads past the end of its
FunctionCallInfo, which is what the sanitizer caught in tablecmds.c
in v1.

Regards,
Rui

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2026-09-15 16:59:32 Re: Global temporary tables
Previous Message Fujii Masao 2026-09-15 16:28:37 Re: remove_useless_joins vs. bug #19560