Re: Vacuum o/p with (full 1, parallel 0) option throwing an error - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Date
Msg-id CAA4eK1LYqw_MN9=MHcxF6ayvmN2NdaxaqJ5e+f2GobBpfC1AjA@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Justin Pryzby <pryzby@telsasoft.com>)
Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 9, 2020 at 11:54 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Thu, 9 Apr 2020 at 14:52, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
>
> > We can do what Mahendra
> > is saying but that will unnecessarily block some syntax and we might
> > need to introduce an extra variable to detect that in code.
>
> ISTM we have been using the expression "specifying the option" in log
> messages when a user wrote the option in the command. But now that
> VACUUM command options can have a true/false it doesn't make sense to
> say like "if the option is specified we cannot do that". So maybe
> "cannot turn on FULL and PARALLEL options" or something would be
> better, I think.
>

Sure, we can change that, but isn't the existing example of similar
message "cannot specify both PARSER and COPY options"  occurs when
both the options have valid values?  If so, we can use a similar
principle here, no?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Next
From: Amit Kapila
Date:
Subject: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error