On Thu, Jul 15, 2021 at 1:40 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Tue, 13 Jul 2021 at 15:30, vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Tue, Jul 13, 2021 at 4:25 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> > >
> > > As it stands, the improvements from (3) seem quite worthwhile. Also,
> > > the patch saves a couple of hundred lines of code, and for me an
> > > optimised executable is around 30 kB smaller, which is more than I
> > > expected.
> >
> > Agreed, it can be handled as part of the 2nd patch. The changes you
> > made apply neatly and the test passes.
>
> Pushed.
>
> I noticed that it's actually safe to call parser_errposition() with a
> null ParseState, so I simplified the ereport() code to just call it
> unconditionally. Also, I decided to not bother using the new function
> in cases with a null ParseState anyway since it doesn't provide any
> meaningful benefit in those cases, and those are the cases most likely
> to targeted next, so it didn't seem sensible to change that code, only
> for it to be changed again later.
>
> Probably the thing to think about next is the few remaining cases that
> throw this error directly and don't have any errdetail or errhint to
> help the user identify the offending option. My preference remains to
> leave the primary error text unchanged, but just add some suitable
> errdetail. Also, it's probably not worth adding a new function for
> those remaining errors, since there are only a handful of them.
Thanks for pushing this patch. I have changed the commitfest status to
"waiting for author" till 0002 patch is posted.
Regards,
Vignesh
