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

From Bharath Rupireddy
Subject Re: Enhanced error message to include hint messages for redundant options error
Date
Msg-id CALj2ACWYNEMgWYdm=KzGngvp_a-kDgqX919FCGmhMd3t22wrXw@mail.gmail.com
Whole thread Raw
In response to Re: Enhanced error message to include hint messages for redundant options error  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Enhanced error message to include hint messages for redundant options error
List pgsql-hackers


On Sat, May 1, 2021, 10:54 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
On 2021-May-01, vignesh C wrote:
> On Thu, Apr 29, 2021 at 10:44 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > On 2021-Apr-29, vignesh C wrote:
> >
> > > Thanks for the comments, please find the attached v3 patch which has
> > > the change for the first part.
> >
> > Looks good to me.  I would only add parser_errposition() to the few
> > error sites missing that.
>
> I have not included parser_errposition as ParseState was not available
> for these errors.

Yeah, it's tough to do that in a few of those such as validator
functions, and I don't think we'd want to do that.  However there are
some cases where we can easily add the parsestate as an argument -- for
example CreatePublication can get it in ProcessUtilitySlow and pass it
down to parse_publication_options; likewise for ExecuteDoStmt.  I didn't
check other places.

IMO, it's not good to change the function API just for showing up parse_position (which is there for cosmetic reasons I feel) in an error which actually has the option name clearly mentioned in the error message.

Best Regards,
Bharath Rupireddy.
EnterpriseDB.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Enhanced error message to include hint messages for redundant options error
Next
From: Tom Lane
Date:
Subject: Regex performance regression induced by match-all code