Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Hüseyin Demir <huseyin.d3r@gmail.com>
From: Hüseyin Demir <huseyin.d3r@gmail.com>
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
Date: 2026-06-22T06:07:16Z
Lists: pgsql-bugs
> > > 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_privs: > - getAggregates() — WHERE clause comparison > - getFuncs() — WHERE clause comparison > - getAdditionalACLs() — SELECT expression (object-level initprivs) > - PREPQUERY_GETCOLUMNACLS — SELECT expression (column-level initprivs, > objsubid != 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.