Re: Possibility to disable `ALTER SYSTEM`
От | Maciek Sakrejda |
---|---|
Тема | Re: Possibility to disable `ALTER SYSTEM` |
Дата | |
Msg-id | CAOtHd0DhASNKkgU7pPkEBi-=Z2e4v9c=PGkJr9O5fiYjvApE1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Possibility to disable `ALTER SYSTEM` (Jelte Fennema-Nio <postgres@jeltef.nl>) |
Ответы |
Re: Possibility to disable `ALTER SYSTEM`
|
Список | pgsql-hackers |
On Mon, Mar 18, 2024 at 7:12 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > > On Mon, 18 Mar 2024 at 13:57, Robert Haas <robertmhaas@gmail.com> wrote: > > I would have been somewhat inclined to find an existing section > > of postgresql.auto.conf for this parameter, perhaps "platform and > > version compatibility". > > I tried to find an existing section, but I couldn't find any that this > new GUC would fit into naturally. "Version and Platform Compatibility > / Previous PostgreSQL Versions" (the one you suggested) seems wrong > too. The GUCs there are to get back to Postgres behaviour from > previous versions. So that section would only make sense if we'd turn > enable_alter_system off by default (which obviously no-one in this > thread suggests/wants). > > If you have another suggestion for an existing category that we should > use, feel free to share. But imho, none of the existing ones are a > good fit. +1 on Version and Platform Compatibility. Maybe it just needs a new subsection there? This is for compatibility with a "deployment platform". The "Platform and Client Compatibility" subsection has just one entry, so a new subsection with also just one entry seems defensible, maybe just "Deployment Compatibility"? I think it's also plausible that there will be other similar settings for managed deployments in the future. > > Even if that is what we're going to do, do we want to call them "guard > > rails"? I'm not sure I'd find that name terribly clear, as a user. > > If anyone has a better suggestion, I'm happy to change it. No better suggestion at the moment, but while I used the term to explain the feature, I also don't think that's a great official name. For one thing, the section could easily be misinterpreted as guard rails for end-users who are new to Postgres. Also, I think it's more colloquial in tone than Postgres docs conventions. Further, I think we may want to change the GUC name itself. All the other GUCs that start with enable_ control planner behavior: maciek=# select name from pg_settings where name like 'enable_%'; name -------------------------------- enable_async_append enable_bitmapscan enable_gathermerge enable_hashagg enable_hashjoin enable_incremental_sort enable_indexonlyscan enable_indexscan enable_material enable_memoize enable_mergejoin enable_nestloop enable_parallel_append enable_parallel_hash enable_partition_pruning enable_partitionwise_aggregate enable_partitionwise_join enable_presorted_aggregate enable_seqscan enable_sort enable_tidscan (21 rows) Do we really want to break that pattern?
В списке pgsql-hackers по дате отправления: