On Mon, May 9, 2022 at 3:44 AM Bharath Rupireddy <bharath.rupireddyforpostg...@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
