On Thu, Jul 15, 2021 at 5:12 PM vignesh C <vignes...@gmail.com> wrote: > > On Thu, Jul 15, 2021 at 1:40 PM Dean Rasheed <dean.a.rash...@gmail.com> wrote: > > > > On Tue, 13 Jul 2021 at 15:30, vignesh C <vignes...@gmail.com> wrote: > > > > > > On Tue, Jul 13, 2021 at 4:25 PM Dean Rasheed <dean.a.rash...@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.
I'm marking this entry in commitfest as committed, I'm planning to work on the other comments later once I finish my current project works. Regards, Vignesh
