Обсуждение: Re: [GENERAL] postgres FDW cost estimation options unrecognized in 9.3-beta1

Lonni J Friedman <netllama@gmail.com> writes:
> nightly=# ALTER SERVER cuda_db10 OPTIONS (SET use_remote_estimate 'true') ;
> ERROR:  option "use_remote_estimate" not found

> Am I doing something wrong, or is this a bug?

[ experiments... ]  You need to say ADD, not SET, to add a new option to
the list.  SET might more appropriately be spelled REPLACE, because it
requires that the object already have a defined value for the option,
which will be replaced.

Our documentation appears not to disclose this fine point, but a look
at the SQL-MED standard says it's operating per spec.  The standard also
says that ADD is an error if the option is already defined, which is a
bit more defensible, but still not exactly what I'd call user-friendly.
And the error we issue for that case is pretty misleading too:

regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true') ;
ALTER SERVER
regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'false') ;
ERROR:  option "use_remote_estimate" provided more than once

I think we could do with both more documentation, and better error
messages for these cases.  In the SET-where-you-should-use-ADD case,
perhaps

ERROR:  option "use_remote_estimate" has not been set
HINT: Use ADD not SET to define an option that wasn't already set.

In the ADD-where-you-should-use-SET case, perhaps

ERROR:  option "use_remote_estimate" is already set
HINT: Use SET not ADD to change an option's value.

The "provided more than once" wording would be appropriate if the same
option is specified more than once in the command text, but I'm not sure
that it's worth the trouble to detect that case.

Thoughts, better wordings?

            regards, tom lane

On Fri, Jul 26, 2013 at 3:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Lonni J Friedman <netllama@gmail.com> writes:
>> nightly=# ALTER SERVER cuda_db10 OPTIONS (SET use_remote_estimate 'true') ;
>> ERROR:  option "use_remote_estimate" not found
>
>> Am I doing something wrong, or is this a bug?
>
> [ experiments... ]  You need to say ADD, not SET, to add a new option to
> the list.  SET might more appropriately be spelled REPLACE, because it
> requires that the object already have a defined value for the option,
> which will be replaced.
>
> Our documentation appears not to disclose this fine point, but a look
> at the SQL-MED standard says it's operating per spec.  The standard also
> says that ADD is an error if the option is already defined, which is a
> bit more defensible, but still not exactly what I'd call user-friendly.
> And the error we issue for that case is pretty misleading too:
>
> regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true') ;
> ALTER SERVER
> regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'false') ;
> ERROR:  option "use_remote_estimate" provided more than once
>
> I think we could do with both more documentation, and better error
> messages for these cases.  In the SET-where-you-should-use-ADD case,
> perhaps
>
> ERROR:  option "use_remote_estimate" has not been set
> HINT: Use ADD not SET to define an option that wasn't already set.
>
> In the ADD-where-you-should-use-SET case, perhaps
>
> ERROR:  option "use_remote_estimate" is already set
> HINT: Use SET not ADD to change an option's value.
>
> The "provided more than once" wording would be appropriate if the same
> option is specified more than once in the command text, but I'm not sure
> that it's worth the trouble to detect that case.
>
> Thoughts, better wordings?

Thanks Tom, I've confirmed that using ADD was the solution.  I think
your suggested updated ERROR & HINT text is an excellent improvement.
It definitely would have given me the clue I was missing earlier.

On Fri, Jul 26, 2013 at 06:28:05PM -0400, Tom Lane wrote:
> Our documentation appears not to disclose this fine point, but a look
> at the SQL-MED standard says it's operating per spec.  The standard also
> says that ADD is an error if the option is already defined, which is a
> bit more defensible, but still not exactly what I'd call user-friendly.
> And the error we issue for that case is pretty misleading too:
>
> regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'true') ;
> ALTER SERVER
> regression=# ALTER SERVER cuda_db10 OPTIONS (use_remote_estimate 'false') ;
> ERROR:  option "use_remote_estimate" provided more than once
>
> I think we could do with both more documentation, and better error
> messages for these cases.  In the SET-where-you-should-use-ADD case,
> perhaps
>
> ERROR:  option "use_remote_estimate" has not been set
> HINT: Use ADD not SET to define an option that wasn't already set.
>
> In the ADD-where-you-should-use-SET case, perhaps
>
> ERROR:  option "use_remote_estimate" is already set
> HINT: Use SET not ADD to change an option's value.
>
> The "provided more than once" wording would be appropriate if the same
> option is specified more than once in the command text, but I'm not sure
> that it's worth the trouble to detect that case.

Where are on this?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +