Обсуждение: EXPLAN redundant options

Поиск
Список
Период
Сортировка

EXPLAN redundant options

От
jian he
Дата:
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?



Re: EXPLAN redundant options

От
"David G. Johnston"
Дата:
On Thu, May 2, 2024 at 6:17 AM jian he <jian.universality@gmail.com> 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.

Re: EXPLAN redundant options

От
"Euler Taveira"
Дата:
On Thu, May 2, 2024, at 10:36 AM, David G. Johnston wrote:
On Thu, May 2, 2024 at 6:17 AM jian he <jian.universality@gmail.com> 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

Re: EXPLAN redundant options

От
Tom Lane
Дата:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, May 2, 2024 at 6:17 AM jian he <jian.universality@gmail.com> 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