Re: Enhanced error message to include hint messages for redundant options error - Mailing list pgsql-hackers

From vignesh C
Subject Re: Enhanced error message to include hint messages for redundant options error
Date
Msg-id CALDaNm3m2E06gFR-Pk9CKukQU=vE7DAenjt+ieB_E4+5WcY6Ng@mail.gmail.com
Whole thread Raw
In response to Re: Enhanced error message to include hint messages for redundant options error  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Enhanced error message to include hint messages for redundant options error  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On Sat, Jul 10, 2021 at 4:14 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Thu, 8 Jul 2021 at 14:40, vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Thu, Jul 8, 2021 at 1:52 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> > >
> > > I sort of like the visual cue of seeing ereport(ERROR ..  since it makes it
> > > clear it will break execution then and there, this will require a lookup for
> > > anyone who don't know the function by heart.  That being said, reducing
> > > duplicated boilerplate has clear value and this reduce the risk of introducing
> > > strings which are complicated to translate.  On the whole I think this is a net
> > > win, and the patch looks pretty good.
> > >
>
> Bikeshedding the function name, there are several similar examples in
> the existing code, but the closest analogs are probably
> errorMissingColumn() and errorMissingRTE(). So I think
> errorConflictingDefElem() would be better, since it's slightly more
> obviously an error.
>

Ok, I will change it to keep it similar.

> Also, I don't think this function should be marked inline -- using a
> normal function ought to help make the compiled code smaller.
>

inline instructs the compiler to attempt to embed the function content
into the calling code instead of executing an actual call. I think we
should keep it inline to reduce the function call.

> A bigger problem is that the patch replaces about 100 instances of the
> error "conflicting or redundant options" with "option \"%s\" specified
> more than once", but that's not always the appropriate thing to do.
> For example, in the walsender code, the error isn't necessarily due to
> the option being specified more than once.
>

This patch intended to change "conflicting or redundant options" to
"option \"%s\" specified more than once" only in case that error is
for option specified more than once. This change is not required. I
will remove it.

> Also, there are cases where def->defname isn't actually the name of
> the option specified, so including it in the error is misleading. For
> example:
>
> CREATE OR REPLACE FUNCTION foo() RETURNS int
> AS $$ SELECT 1 $$ STABLE IMMUTABLE;
>
> ERROR:  option "volatility" specified more than once
> LINE 2: AS $$ SELECT 1 $$ STABLE IMMUTABLE;
>                                  ^
>
> and in this case "volatility" is an internal string, so it won't get translated.
>
> I'm inclined to think that it isn't worth the effort trying to
> distinguish between conflicting options, options specified more than
> once and faked-up options that weren't really specified. If we just
> make errorConflictingDefElem() report "conflicting or redundant
> options", then it's much easier to update calling code without making
> mistakes. The benefit then comes from the reduced code size and the
> fact that the patch includes pstate in more places, so the
> parser_errposition() indicator helps the user identify the problem.
>
> In file_fdw_validator(), where there is no pstate, it's already using
> "specified more than once" as a hint to clarify the "conflicting or
> redundant options" error, so I think we should leave that alone.

This patch intended to change "conflicting or redundant options" to
"option \"%s\" specified more than once" only in case that error is
for option specified more than once. Thanks for pointing out a few
places where the actual error "conflicting or redundant options"
should be left as it is. I will post a new patch which will remove the
conflicting options error scenarios, which were not targeted in this
patch.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: proposal: possibility to read dumped table's name from file
Next
From: Alvaro Herrera
Date:
Subject: Re: Pipeline mode and PQpipelineSync()