| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 16:07:36 |
| Message-ID: | CA+Tgmob=4hRHeZ_L=B=ThFsCt3PsFCiega3M=KiyiPbP1VQv1Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 16, 2021 at 10:45 AM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> You are talking about mismatches in the other direction, aren't you? I was responding to Robert's point that new gucs could appear, and old gucs disappear. That seems analogous to new functions appearing and old functions disappearing. If you upgrade (not downgrade) the .so, the new gucs and functions will be in the .so, but won't be callable/grantable from sql until the upgrade script runs. The old gucs and functions will be missing from the .so, and attempts to call them/grant them from sql before the upgrade will fail. What am I missing here?
It's true that we could impose such a restriction, but I don't think
we should. If I install a different .so, I want the new GUCs to be
grantable immediately, without running any separate DDL.
I also don't think we should burden extension authors with putting
stuff in their upgrade scripts for this. We should solve the problem
in our code rather than forcing them to do so in theirs.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2021-11-16 16:25:37 | Re: support for MERGE |
| Previous Message | Andrew Dunstan | 2021-11-16 16:05:43 | Re: Test::More version |