On Wed, May 27, 2020 at 9:33 PM David G. Johnston <david.g.johns...@gmail.com> wrote: > I'm not seeing enough similarity with the reasons for, and specific > behaviors, of those previous GUCs to dismiss this proposal on that basis > alone. These are "crap we messed things up" switches that alter a query > behind the scenes in ways that a user cannot do through SQL - they simply > provide for changing a default that we already allow the user to override > per-query. Its akin to "DateStyle" and its pure cosmetic influencing > ease-of-use option rather than some changing the fundamental structural > meaning of '\n'
Well, I think it's usually worse to have two possible behaviors rather than one. Like, a lot of people have probably made the mistake of running EXPLAIN ANALYZE without realizing that it's actually running the query, and then been surprised or dismayed afterwards. But each person only has to learn that once. If we had a GUC controlling this behavior, then you'd have to always be aware of the setting on any particular system on which you might be thinking of running the command. Likewise, if you write an application or tool of some sort that uses EXPLAIN ANALYZE, it has to be aware of the GUC value, or it won't work as expected on some systems. This is the general problem with behavior-changing GUCs. I kind of have mixed feelings about this. On the one hand, it sucks for operators of individual systems not to be able to customize things so as to produce the behavior they want. On the other hand, each one you add makes it harder to write code that will work the same way on every PostgreSQL system. I don't think the problem would be as bad in this particular case as in some others that have been proposed, mostly because EXPLAIN ANALYZE isn't widely-used by applications, so maybe it's worth considering. But on the whole, I'm inclined to agree with Tom that it's better not to create too many ways for fundamental behavior of the system to vary from one installation to another. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
