Re: updates for handling optional argument in system functions - Mailing list pgsql-hackers

> On Apr 8, 2026, at 07:44, Mark Wong <markwkm@gmail.com> wrote:
>
> On Wed, Apr 08, 2026 at 01:28:29AM +0200, Andreas Karlsson wrote:
>> On 4/8/26 12:26 AM, Andreas Karlsson wrote:
>>> On 4/2/26 8:36 PM, Mark Wong wrote:
>>>> I've attached v5, simply a needed rebase due to some other churn in
>>>> pg_proc.dat.
>>>
>>> Nice, I like the patch. The code changes looks good and I like the
>>> removal of these duplicate functions and use of default arguments. But I
>>> think the names of the arguments should be aligned with the names we
>>> have in the documentation. And that may mean that we should change the
>>> documentation.
>> Forgot to attach rebased patches.
>
> Another rebase needed so quickly? :)  Thanks for the assist!
>
> Regards,
> Mark

I still have the question as I raised previously. Let’s use 0001 as an example. 0001 removes function 1573.

Say, an existing view depends on 1573:
```
evantest=# CREATE VIEW v_ruledef AS
evantest-# SELECT pg_get_ruledef(oid) AS ruledef
evantest-# FROM pg_rewrite
evantest-# WHERE rulename = '_RETURN';
CREATE VIEW
```

The view is stored as:
```
 _RETURN  | v_ruledef | ({QUERY :commandType 1 :querySource 0 :canSetTag true :utilityStmt <> :resultRelation 0
:forPortionOf<> :hasAggs false :hasWindowFuncs false :hasTargetSRFs false :hasSubLinks false :hasDistinctOn false
:hasRecursivefalse :hasModifyingCTE false :hasForUpdate false :hasRowSecurity false :hasGroupRTE false :isReturn false
:cteList<> :rtable ({RANGETBLENTRY :alias <> :eref {ALIAS :aliasname pg_rewrite :colnames ("oid" "rulename" "ev_class"
"ev_type""ev_enabled" "is_instead" "ev_qual" "ev_action")} :rtekind 0 :relid 2618 :inh true :relkind r :rellockmode 1
:perminfoindex1 :tablesample <> :lateral false :inFromCl true :securityQuals <>}) :rteperminfos ({RTEPERMISSIONINFO
:relid2618 :inh true :requiredPerms 2 :checkAsUser 0 :selectedCols (b 8 9) :insertedCols (b) :updatedCols (b)})
:jointree{FROMEXPR :fromlist ({RANGETBLREF :rtindex 1}) :quals {OPEXPR :opno 93 :opfuncid 62 :opresulttype 16 :opretset
false:opcollid 0 :inputcollid 950 :args ({VAR :varno 1 :varattno 2 :vartype 19 :vartypmod -1 :varcollid 950
:varnullingrels(b) :varlevelsup 0 :varreturningtype 0 :varnosyn 1 :varattnosyn 2 :location -1} {CONST :consttype 19
:consttypmod-1 :constcollid 950 :constlen 64 :constbyval false :constisnull false :location -1 :constvalue 64 [ 95 82
6984 85 82 78 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
00 0 0 ]}) :location -1}} :mergeActionList <> :mergeTargetRelation 0 :mergeJoinCondition <> :targetList ({TARGETENTRY
:expr{FUNCEXPR :funcid 1573 :funcresulttype 25 :funcretset false :funcvariadic false :funcformat 0 :funccollid 100
:inputcollid0 :args ({VAR :varno 1 :varattno 1 :vartype 26 :vartypmod -1 :varcollid 0 :varnullingrels (b) :varlevelsup
0:varreturningtype 0 :varnosyn 1 :varattnosyn 1 :location -1}) :location -1} :resno 1 :resname ruledef :ressortgroupref
0:resorigtbl 0 :resorigcol 0 :resjunk false}) :override 0 :onConflict <> :returningOldAlias <> :returningNewAlias <>
:returningList<> :groupClause <> :groupDistinct false :groupByAll false :groupingSets <> :havingQual <> :windowClause
<>:distinctClause <> :sortClause <> :limitOffset <> :limitCount <> :limitOption 0 :rowMarks <> :setOperations <>
:constraintDeps<> :withCheckOptions <> :stmt_location -1 :stmt_len -1}) 
```

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
recommendedway to handle this kind of situation that I am not aware of? 

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