Re: Enhanced error message to include hint messages for redundant options error

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Enhanced error message to include hint messages for redundant options error
Date: 2021-05-08 08:50:34
Message-ID: CALj2ACXrm+Pj5bdwF2sfqRU_c5L=yXzof4FziZ6SpHAF7VHATA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 8, 2021 at 12:01 PM houzj(dot)fnst(at)fujitsu(dot)com
<houzj(dot)fnst(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-05-08 10:33:41 Re: plan with result cache is very slow when work_mem is not enough
Previous Message Michael Paquier 2021-05-08 08:46:00 Re: Simplify backend terminate and wait logic in postgres_fdw test