On Tue, Jun 2, 2020 at 10:25 AM Bruce Momjian <br...@momjian.us> 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. > > I can see where it would have saved Vik some effort but I'm not seeing how an email without a patch is better for the rest of us than having a concrete change to discuss. At this point, given the original goal of the patch was to try and grease a smoother path to changing the default for BUFFERS, and that people seem OK with doing just that without having this patch, I'd say we should just change the default and forget this patch. There hasn't been any other demand from our users for this capability and I also doubt that having BUFFERS on by default is going to bother people. However, the one default on option, TIMING, also has a nice blurb about why having it enabled can be problematic and to consider turning it off. Is there a similar "oh by the way" with BUFFERS that I just haven't come across that would making having it on cause more problems than it solves? David J.
