On Wed, Feb 25, 2026 at 12:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Because the result of the restore will not match how things were
> in the source database? True, we do not have any way to make them
> match, but that doesn't mean that pg_dumpall has fulfilled all
> expectations.
That's a fair point. On the flip side, the grantor in v15- is
basically a comment. From v16, it behaves in the way we'd normally
expect: a role grant depends on the grantor in the same way that a
table grant depends on the grantor in the table ACL, just with a
different catalog representation. In v15-, it has no functional
impact.
> > Moreover, we'll emit essentially the same warning for the member case,
> > where the warning does point to a problem that someone might want to
> > think about correcting, and exactly the same warning against a v16+
> > database where it indicates that something has actually gone wrong.
>
> That's a fair point, but maybe it could be addressed by phrasing the
> message differently for the different cases.
I like that idea. I think the biggest danger here for users is
actually that we have to convert the pre-v16 "it's a comment" catalog
state into a v16+ "it's a real thing that works like the rest of the
authorization system" catalog state, and there's no way to do that
perfectly because we're starting from a busted catalog representation.
It seems reasonable to somehow let people know that whatever we're
doing is an approximation. If we can make the "invalid grantor from
pre-v16" sound like "don't panic but we have to patch some stuff up so
you can upgrade" and the "invalid grantor for v16+" and "invalid
member" cases sound like "uh oh, it seems like something got
corrupted" then I'm entirely happy with that state of affairs
(assuming we also resume dumping the GRANT, of course).
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
