Re: EXPLAN redundant options
"David G. Johnston" writes: > On Thu, May 2, 2024 at 6:17 AM jian he wrote: >> explain (verbose, verbose off, analyze on, analyze off, analyze on) > I have no desire to introduce breakage here. The implemented concept is > actually quite common. The inconsistency with COPY seems like a minor > point. It would influence my green field choice but not enough for > changing long-standing behavior. The argument for changing this would be consistency, but if you want to argue for it on those grounds, you'd need to change *every* command that acts that way. I really doubt EXPLAIN is the only one. There's also a theological argument to be had about which behavior is preferable. For my own taste, I like last-one-wins. That's extremely common with command line switches, for instance. So maybe we should be making our commands consistent in the other direction. regards, tom lane
Re: EXPLAN redundant options
On Thu, May 2, 2024, at 10:36 AM, David G. Johnston wrote: > On Thu, May 2, 2024 at 6:17 AM jian he wrote: >> explain (verbose, verbose off, analyze on, analyze off, analyze on) > > I would just update this paragraph to note the last one wins behavior. > > "When the option list is surrounded by parentheses, the options can be > written in any order. However, if options are repeated the last one listed > is used." > > I have no desire to introduce breakage here. The implemented concept is > actually quite common. The inconsistency with COPY seems like a minor point. > It would influence my green field choice but not enough for changing > long-standing behavior. > There is no policy saying we cannot introduce incompatibility changes in major releases. If you check for "conflicting or redundant options" or "errorConflictingDefElem", you will notice that various SQL commands prevent you to inform redundant options. IMO avoid redundant options is a good goal because (i) it keeps the command short and (b) it doesn't require you to check all options to figure out what's the current option value. If the application is already avoiding redundant options for other commands, the probability of allowing it just for EXPLAIN is low. postgres=# create database foo with owner = bar owner = xpto; ERROR: conflicting or redundant options LINE 1: create database foo with owner = bar owner = xpto; ^ postgres=# create user foo with createdb login createdb; ERROR: conflicting or redundant options LINE 1: create user foo with createdb login createdb; ^ -- Euler Taveira EDB https://www.enterprisedb.com/
Re: EXPLAN redundant options
On Thu, May 2, 2024 at 6:17 AM jian he wrote: > explain (verbose, verbose off, analyze on, analyze off, analyze on) > > I would just update this paragraph to note the last one wins behavior. "When the option list is surrounded by parentheses, the options can be written in any order. However, if options are repeated the last one listed is used." I have no desire to introduce breakage here. The implemented concept is actually quite common. The inconsistency with COPY seems like a minor point. It would influence my green field choice but not enough for changing long-standing behavior. David J.
EXPLAN redundant options
hi. just found out we can: explain (verbose, verbose off, analyze on, analyze off, analyze on) select count(*) from tenk1; similar to COPY, do we want to error out these redundant options?
