On Mon, May 9, 2022 at 3:44 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> Thanks for providing thoughts. I'm personally not in favour of adding
> any new syntax, as the new syntax would require some education and
> changes to other layers. I see some downsides with new syntax:
> 1) It will be a bit difficult to deal with the parameters that don't
> have ranges (as pointed out by Robert upthread).
> 2) It will be a bit difficult to enforce platform specific
> configurations at run time - (say the user has scaled-up the host
> system/VM, now has more vcores, RAM and now they will have more memory
> and number of workers to use for their setting).
> 3) If someone wants to disallow users setting some core/extension
> configuration parameters which can make the server unmanageable (block
> setting full_page_writes to off, zero_damaged_pages to on, fsync to
> off, log levels to debug5, huge_pages to on, all the command options
> (archive_command, restore_command .... etc.).
>
> IMO, the hook and a sample extension in the core helps greatly to
> achieve the above.
I don't think that any of these are very fundamental objections. Every
feature requires education, many require changes to various layers,
and the fact that some parameters don't have ranges is a topic to
think about how to handle, not a reason to give up on the idea. (2)
may mean that some users - large service providers, in particular -
prefer the hook to the SQL syntax, but that's not a reason not to have
SQL syntax. (3) basically seems like an argument that people my do
dumb things with it, but that's true of every feature.
I'm not sure that a hook and sample extension is unacceptable; it
might be fine. But I think it is not saying anything other than the
truth to say that this will benefit large service providers while
leaving the corresponding problem unsolved for ordinary end users. And
I remain of the opinion that that's not great.
--
Robert Haas
EDB: http://www.enterprisedb.com
