Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
От | Amit Kapila |
---|---|
Тема | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Дата | |
Msg-id | CAA4eK1KXffxOekMuD=nvnvvmhOz7NgE45DYN-acy9QR7hHtXoA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
On Thu, Aug 22, 2013 at 9:34 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote: >> * Amit Kapila (amit.kapila16@gmail.com) wrote: >> > This can resolve the problem of whether to read auto file rather >> > cleanly, so the idea is: >> > >> > Enable/Disable reading of auto file >> > ----------------------------------------------------- >> > a. Have a new include in postresql.conf >> > #include_auto_conf_file postgresql.auto.conf >> > as it is a special include, we can read this file relative to data >> > directory. > > The big advantage of using 'include_auto_conf_file' and not simply > 'include' is that we can issue an error from ALTER SYSTEM SET if that is > not set. > >> > Enable/Disable Alter System command >> > ----------------------------------------------------------- >> > This can be achieved in 3 ways: >> > a. Check before executing Alter System if include directive is >> > disabled, then just issue a warning to user and proceed with command. >> > b. Check before executing Alter System if include directive is >> > disabled, then just issue an error and stop. >> >> It doesn't make sense for it to be a 'warning' with this- the >> parameter specifies the file to use. If you don't know what file to >> use, how you can possibly do anything but return an error? > > Agreed. No sense in allowing users to add things to the 'auto' file > when the auto file is inactive. > >> Note that I *like* that about this approach. >> >> There are a few other considerations with this- >> >> - What should the default be? (Still thinking 'off' myself) > > Probably, but we might need to wait until we have a final API for a > decision on that. > >> - What happens if the user specifies 'postgresql.conf'? I'm thinking we >> would disallow such insanity (as that's what it is, imv..) by having >> an identifier in the file that this is the PG "auto conf" file. > > I am thinking they can't include a value equal to 'config_file', which > is normally postgresql.conf. I am not a big fan of looking for special > text in files. This might be complex to check, though, because of path > changes --- we might just disallow the basement from matching the > basename of config_file. Right, I also think that as file and location are fixed, so it can be detected with name. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: