Re: Enhanced error message to include hint messages for redundant options error - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Enhanced error message to include hint messages for redundant options error
Date
Msg-id 20210426143629.GA9618@alvherre.pgsql
Whole thread Raw
In response to Re: Enhanced error message to include hint messages for redundant options error  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Enhanced error message to include hint messages for redundant options error  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On 2021-Apr-26, Bharath Rupireddy wrote:

> Thanks! IMO, it is better to change the error message to "option
> \"%s\" specified more than once" instead of adding an error detail.
> Let's hear other hackers' opinions.

Many other places have the message "conflicting or redundant options",
and then parser_errposition() shows the problem option.  That seems
pretty unhelpful, so whenever the problem is the redundancy I would have
the message be explicit about that, and about which option is the
problem:
  errmsg("option \"%s\" specified more than once", "someopt")
Do note that wording it this way means only one translatable message,
not dozens.

In some cases it is possible that you'd end up with two messages, one
for "redundant" and one for the other ways for options to conflict with
others; for example collationcmds.c has one that's not as obvious, and
force_quote/force_quote_all in COPY have their own thing too.

I think we should do parser_errposition() wherever possible, in
addition to the wording change.

-- 
Álvaro Herrera       Valdivia, Chile
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
       more or less, right?
<crab> i.e., "deadly poison"



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?
Next
From: Peter Eisentraut
Date:
Subject: Re: compute_query_id and pg_stat_statements