Le mar. 26 mai 2020 à 04:27, Stephen Frost <sfr...@snowman.net> a écrit :
> Greetings, > > * Michael Paquier (mich...@paquier.xyz) wrote: > > On Mon, May 25, 2020 at 09:36:50PM -0400, Bruce Momjian wrote: > > > I am not excited about this new feature. Why do it only for EXPLAIN? > > Would probably help to understand what your thinking is here regarding > how it could be done for everything...? In particular, what else are > you thinking it'd be sensible for? > > > > That is a log of GUCs. I can see this becoming a feature creep > > > disaster. > > I'd only view it as a feature creep disaster if we end up extending it > to things that don't make any sense.. I don't see any particular reason > why we'd have to do that though. On the other hand, if there's a clean > way to do it for everything, that'd be pretty neat. > > > FWIW, Neither am I. This would create an extra maintenance cost, and > > I would not want such stuff to spread to other commands either, say > > CLUSTER, VACUUM, REINDEX, etc. And note that it is always possible to > > do that with a small extension using the utility hook and some > > pre-loaded user-settable GUCs. > > The suggestion to "go write C code that will be loaded via a utility > hook" is really entirely inappropriate here. > > This strikes me as a pretty reasonable 'creature comfort' kind of idea. > Inventing GUCs to handle it is maybe not the best approach, but we > haven't really got anything better right at hand- psql can't parse > general SQL, today, and hasn't got it's own idea of "how to run > explain". On the other hand, I could easily see a similar feature > being included in pgAdmin4 where running explain is clicking on a button > instead of typing 'explain'. > > To that end- what if this was done client-side with '\explain' or > similar? Basically, it'd work like \watch or \g but we'd have options > under pset like "explain_analyze t/f" and such. I feel like that'd also > largely address the concerns about how this might 'feature creep' to > other commands- because those other commands don't work with a query > buffer, so it wouldn't really make sense for them. > > As for the concerns wrt explain UPDATE or explain DETELE actually > running the query, that's what transactions are for, and if you don't > feel comfortable using transactions or using these options- then don't. > > This means you'll always have to check if the new GUCs are set up in a way it will actually execute the query or to open a transaction for the same reason. This is a huge behaviour change where people might lose data. I really don't like this proposal (the new GUCs). -- Guillaume.
