Re: Major Version Upgrade failure due to orphan roles entries in catalog - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Major Version Upgrade failure due to orphan roles entries in catalog
Date
Msg-id 1103272.1772227345@sss.pgh.pa.us
Whole thread Raw
In response to Re: Major Version Upgrade failure due to orphan roles entries in catalog  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Major Version Upgrade failure due to orphan roles entries in catalog
List pgsql-bugs
I wrote:
> I'd be content to use those wordings (except I think our style
> guide wants detail to be punctuated like a sentence).  I'll wait
> a day or so to see if anyone has a better idea, though.

When I looked at the code more closely, I realized that it already
doesn't dump grantors when dumping from pre-v16.  I'm inclined to
think that is an overreaction to the possible unreliability of the
data (and from your comment upthread you might agree).  But given
the lack of complaints about it, let's leave that as-is for now.
The immediate problem is that the code is allowing a null grantor to
suppress the GRANT altogether, *even if it's not going to use the
grantor*.  Clearly that's silly.  But if we're not going to use
the grantor, let's skip trying to fetch it, which means we also
don't need the info-level variant of the message.

So I end with the attached draft patch.

            regards, tom lane

#text/x-diff; name="v1-clean-up-dumpRoleMembership.patch" [v1-clean-up-dumpRoleMembership.patch]
/home/tgl/pgsql/v1-clean-up-dumpRoleMembership.patch



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_get_viewdef() produces non-round-trippable SQL for views with USING join on mismatched integer types
Next
From: Tom Lane
Date:
Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog