MIME-Version: 1.0
References: <19483-80de42dc4e62cfd6@postgresql.org>
 <CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg@mail.gmail.com>
 <104812.1780847519@sss.pgh.pa.us>
 <CAB5wL7bo-7okBCJ24fdVn4UhnuPLPG22eQjaLJZ9GJtv0FEWMg@mail.gmail.com>
 <CAB5wL7bunPCi93Bwi7zN_1gFAZhKLwS=Fsub91SW417xujGtNA@mail.gmail.com>
 <CAB5wL7aKGFFEF1SM54GxvaQPH=7Bs=HuUCqi7F4Ve025+Z950A@mail.gmail.com>
 <CAB5wL7aK6UaukMSegzEG68y0VrKOg7wFnPNRaDaHreBf2iVWag@mail.gmail.com>
 <d305af372949be0c2c4155168ca7ba97e160bc52.camel@cybertec.at>
 <5184088806e70ed5db7e83bd6540a016b3802c1d.camel@cybertec.at>
 <CAB5wL7ZuFwu2Sd-xmn-w5-BbrKk_Mu_1ubYow_qaqFGhJOiMXw@mail.gmail.com>
In-Reply-To: 
 <CAB5wL7ZuFwu2Sd-xmn-w5-BbrKk_Mu_1ubYow_qaqFGhJOiMXw@mail.gmail.com>
From: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>
Date: Mon, 22 Jun 2026 08:07:16 +0200
Message-ID: 
 <CAB5wL7ai8AiaFV6B8J=w6vK1Q6Z9Hmp_y3PFL2Zzpx6Y8xPZ2A@mail.gmail.com>
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv
 catalog table
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAB5wL7ai8AiaFV6B8J%3Dw6vK1Q6Z9Hmp_y3PFL2Zzpx6Y8xPZ2A%40mail.gmail.com>
Precedence: bulk

>
> > Further testing shows that changing this query isn't enough.
> > There are three more places where pg_dump queries pg_init_privs
> > (in getAggregates, getFuncs and dumpTable).
> >
> > So we'd have to use a similarly ugly query in all these places,
> > which doesn't seem particularly attractive and introduces
> > considerable code duplication.
> >
> > One approach I can think of is to have a macro SAFE_INITPRIVS
> > that contains the ugly subquery and is used in all these places.
> >
> > The other idea is to do some post-processing of the aclitems
> > found, but they are in string form and would need to get parsed
> > again, which doesn't look attractive either.
>
>
> v4 applies the filter at all four sites where pg_dump queries pg_init_pri=
vs:
> - getAggregates() =E2=80=94 WHERE clause comparison
> - getFuncs() =E2=80=94 WHERE clause comparison
> - getAdditionalACLs() =E2=80=94 SELECT expression (object-level initprivs=
)
> - PREPQUERY_GETCOLUMNACLS =E2=80=94 SELECT expression (column-level initp=
rivs,
> objsubid !=3D 0)
>
> Secondly to avoid duplicating the multi-line subquery at every call
> site, I introduced a SAFE_INITPRIVS(col) macro.

One question from my side: can't we use function instead of macro ?
Would it be more accurate for future readers ?

Wanted to ask your opinion besides the v4 patch.

Regards,
Demir.