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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, 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-07-10 10:44:18
Message-ID: CAEZATCVnD2QqbURdM5zN4CShFdj8-_HBZuB3kiZk6DKZpWGK9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 8 Jul 2021 at 14:40, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, Jul 8, 2021 at 1:52 AM Daniel Gustafsson <daniel(at)yesql(dot)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.

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

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.

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.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2021-07-10 11:00:49 Re: Enhanced error message to include hint messages for redundant options error
Previous Message Fabien COELHO 2021-07-10 09:36:13 Re: pgbench logging broken by time logic changes