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 CALj2ACXrm+Pj5bdwF2sfqRU_c5L=yXzof4FziZ6SpHAF7VHATA@mail.gmail.com
Whole thread Raw
In response to RE: Enhanced error message to include hint messages for redundant options error  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Enhanced error message to include hint messages for redundant options error  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Sat, May 8, 2021 at 12:01 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> > > > Thanks! The v5 patch looks good to me. Let's see if all agree on the
> > > > goto duplicate_error approach which could reduce the LOC by ~80.
> > >
> > > I think the "goto duplicate_error" approach looks good, it avoids
> > > duplicating the same error code multiple times.
> >
> > Thanks. I will mark the v5 patch "ready for committer" if no one has comments.
>
> Hi,
>
> I looked into the patch and noticed a minor thing.
>
> +       return;                         /* keep compiler quiet */
>  }
>
> I think we do not need the comment here.
> The compiler seems not require "return" at the end of function
> when function's return type is VOID.
>
> In addition, it seems better to remove these "return;" like what
> commit "3974c4" did.

It looks like that commit removed the plain return statements for a
void returning functions. I see in the code that there are return
statements that are there right after ereport(ERROR, just to keep the
compiler quiet. Here in this patch also, we have return; statements
after ereport(ERROR, for void returning functions. I'm not sure
removing them would cause some compiler warnings on some platforms
with some other compilers. If we're not sure, I'm okay to keep those
return; statements. Thoughts?

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Simplify backend terminate and wait logic in postgres_fdw test
Next
From: Tomas Vondra
Date:
Subject: Re: plan with result cache is very slow when work_mem is not enough