On Tue, Jun 2, 2020 at 09:29:09PM +0200, Vik Fearing wrote: > On 6/2/20 7:25 PM, Bruce Momjian wrote: > > On Wed, May 27, 2020 at 11:10:35AM +0200, Vik Fearing wrote: > >> On 5/27/20 7:27 AM, David G. Johnston wrote: > >>>> Would you propose we just error out in that case, or should we > >>>> silently enable the required option, or disable the conflicting > >>>> option? > >>>> > >>> The same thing we do today...ignore options that require analyze if > >>> analyze > >>> is not specified. There are no other options documented that are > >>> dependent > >>> with options besides than analyze. The docs say timing defaults to on, > >>> its > >>> only when explicitly specified instead of being treated as a default that > >>> the user message appears. All the GUCs are doing is changing the default. > >> > >> > >> Yes, the patch handles this case the way you describe. In fact, the > >> patch doesn't (or shouldn't) change any behavior at all. > > > > I think it would have been helpful if an email explaining this idea for > > discussion would have been posted before a patch was generated and > > posted. > > Why?
Because you often have to go backwards to religitate things in the patch, rather than opening with the design issues. Our TODO list is very clear about this: https://wiki.postgresql.org/wiki/Todo Desirability -> Design -> Implement -> Test -> Review -> Commit -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee