From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | AKASH <akashbhujbal7051(at)gmail(dot)com> |
Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Evidence of Ownership Issues During Restoration of Extension Member Objects |
Date: | 2025-01-28 05:56:32 |
Message-ID: | CAKFQuwYMWQRdhj0SPiW0KnmwMOi0pEmdyWKeyOxDa+GSb5U6VA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Monday, January 27, 2025, AKASH <akashbhujbal7051(at)gmail(dot)com> wrote:
> Addressing this limitation—either through improved documentation or
> tooling adjustments—would greatly benefit users managing complex permission
> models.
>
That most likely means taking Tom’s email of restrictions and adding them
to the documentation somewhere. We don’t really have a good way to modify
tooling to prohibit superusers from doing stuff like this that breaks their
system. But this should not be impacting production use cases if proper
testing of backup/restore is happening.
As an aside, none of the use cases are framed to directly motivate why you
would take the actions described, so we are still just left seeing
unnecessary attempts to make unsupported changes to the system permissions
setup and responding with “don’t do that”. An extension like pg_trgm has
little to no security implications necessitating complex permission setup,
AFAICS.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-01-28 06:33:50 | Re: Evidence of Ownership Issues During Restoration of Extension Member Objects |
Previous Message | Christophe Pettus | 2025-01-28 05:47:15 | Re: Evidence of Ownership Issues During Restoration of Extension Member Objects |