| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Granting SET and ALTER SYSTE privileges for GUCs |
| Date: | 2021-11-16 15:24:51 |
| Message-ID: | 0C86AB2D-87F0-43C0-A03C-02A28FFD3D9C@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Nov 16, 2021, at 7:03 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges.
The burden isn't on the installer of an extension. As implemented, it's the extension's installation .sql file that sets it up, and the upgrade .sql files that make adjustments, if necessary.
> And
> if somebody then loads up a different .so for that extension, the set
> of GUCs that it provides can change without any DDL being executed.
> New GUCs could appear, and old GUCs could vanish.
Well, the same is true for functions, right? If you add, remove, or redefine functions in the extension, you need an upgrade script that defines the new functions, removes the old ones, changes function signatures, or whatever. The same is true here for GUCs.
I don't think we support using a .so that is mismatched against the version of the extension that is installed.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-11-16 15:28:57 | Re: Granting SET and ALTER SYSTE privileges for GUCs |
| Previous Message | Robert Haas | 2021-11-16 15:23:27 | Re: Granting SET and ALTER SYSTE privileges for GUCs |