On Tue, Aug 20, 2013 at 6:55 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >> On Tue, Aug 20, 2013 at 6:21 PM, Stephen Frost <sfr...@snowman.net> wrote: >> > I'm not particularly set on this.. Why not create the file initially? >> If by default this feature needs to be disabled, then it is not >> must to have at initdb time. > > I don't see how the two are related. You could never use two-phase > commit (could even disable it), yet we still create things in the data > directory to support it. Having a file in the data directory which > isn't used by default isn't that big a deal, imv.
Yes, it can be done, what I wanted to say it is not a "must", rather a good to have thing. >> Also you mentioned below line upthread which I understood as you >> don't like idea of creating empty file at initdb >> time: >> "If it's enabled by default, then we need to ship an 'auto' file which is >> empty by default... I don't particularly like that" > > What I didn't like was having an empty file be accepted as 'valid', but > you need to have some kind of bootstrap mechanism. Telling users "run > this command and then ignore the warning" is certainly bad. A better > option might be to have a *non-empty* auto.conf be generated, where all > it has in it is some kind of identifier, perhaps even just > "enable_alter_system = on" which we could then key off of to see if > ALTER SYSTEM has been set up to be allowed or not. Wouldn't it be complicated to handle this way rather then by having include directive. If include directive is enabled then the autofile will be read else no need to read it. If we want to have separate identifier to judge ALTER SYSTEM is enable or not, then it is better to go with a new GUC. >> I think if we choose to use include directive as a way to >> enable/disable this feature, it will not be good to allow change of >> this parameter with Alter System. > > I agree, but then we need to add it to the list of things ALTER SYSTEM > can't modify (if the include is implemented as a GUC, that is; I've not > looked). I have checked and it seems to be just parse time thing. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers