On Sat, May 1, 2021, 10:54 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> On 2021-May-01, vignesh C wrote: > On Thu, Apr 29, 2021 at 10:44 PM Alvaro Herrera <alvhe...@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. >
