public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Mark Wong <[email protected]>
Cc: Andreas Karlsson <[email protected]>
Cc: [email protected]
Subject: Re: updates for handling optional argument in system functions
Date: Wed, 8 Apr 2026 09:33:56 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <adWWxf5YrHATATw3@ltdrgnflg2>
References: <aTiwu9o8vBkLreAL@ltdrgnflg2>
	<ac63G6p1LAdbsca0@ltdrgnflg2>
	<[email protected]>
	<[email protected]>
	<adWWxf5YrHATATw3@ltdrgnflg2>



> On Apr 8, 2026, at 07:44, Mark Wong <[email protected]> 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 :hasRecursive false :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 :perminfoindex 1 :tablesample <> :lateral false :inFromCl true :securityQuals <>}) :rteperminfos ({RTEPERMISSIONINFO :relid 2618 :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 69 84 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 0 0 0 0 ]}) :location -1}} :mergeActionList <> :mergeTargetRelation 0 :mergeJoinCondition <> :targetList ({TARGETENTRY :expr {FUNCEXPR :funcid 1573 :funcresulttype 25 :funcretset false :funcvariadic false :funcformat 0 :funccollid 100 :inputcollid 0 :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 recommended way 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/

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: updates for handling optional argument in system functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox