Re: Default gucs for EXPLAIN

On 5/26/20 1:30 PM, David Rowley wrote:
> On Tue, 26 May 2020 at 13:36, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> On Sat, May 23, 2020 at 06:16:25PM +0000, Nikolay Samokhvalov wrote:
>>> This is a very good improvement! Using information about buffers is my favorite
>>> way to optimize queries.
>>>
>>> Not having BUFFERS enabled by default means that in most cases, when asking for
>>> help, people send execution plans without buffers info.
>>>
>>> And it's simply in on event to type "(ANALYZE, BUFFERS)" all the time.
>>>
>>> So I strongly support this change, thank you, Vik.
>>
>> I am not excited about this new feature.
> 
> I'm against adding GUCs to control what EXPLAIN does by default.
> 
> A few current GUCs come to mind which gives external control to a
> command's behaviour are:
> 
> standard_conforming_strings
> backslash_quote
> bytea_output
> 
> It's pretty difficult for application authors to write code that will
> just work due to these GUCs. We end up with GUCs like
> escape_string_warning to try and help application authors find areas
> which may be problematic.
> 
> It's not an easy thing to search for in the archives, but we've
> rejected GUCs that have proposed new ways which can break applications
> in this way. For example [1]. You can see some arguments against that
> in [2].
> 
> Now, there are certainly far fewer applications out there that will
> execute an EXPLAIN, but the number is still above zero. I imagine the
> authors of those applications might get upset if we create something
> outside of the command that controls what the command does. Perhaps
> the idea here is not quite as bad as that as applications could still
> override the options by mentioning each EXPLAIN option in the command
> they send to the server. However, we're not done adding new options
> yet, so by doing this we'd be pretty much insisting that applications
> that use EXPLAIN know about all EXPLAIN options for the server version
> they're connected to. That seems like a big demand given that we've
> been careful to still support the old
> EXPLAIN syntax after we added the new way to specify the options in parenthesis.


Nah, this argument doesn't hold.  If an app wants something on or off,
it should say so.  If it doesn't care, then it doesn't care.

Are you saying we should have all new EXPLAIN options off forever into
the future because apps won't know about the new data?  I guess we
should also not ever introduce new plan nodes because those won't be
known either.

I'm not buying that.
-- 
Vik Fearing