Re: CREATE COLLATION - check for duplicate options and error out if found one - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: CREATE COLLATION - check for duplicate options and error out if found one
Date
Msg-id CALj2ACWNXQCus35Mrjc_=3zo35OZmwGx1UFLsOoVQUc1A8enxQ@mail.gmail.com
Whole thread Raw
In response to Re: CREATE COLLATION - check for duplicate options and error out if found one  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: CREATE COLLATION - check for duplicate options and error out if found one
List pgsql-hackers
On Fri, Jul 16, 2021 at 1:32 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Fri, 16 Jul 2021 at 06:40, Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >
> > 1) Duplicate option check for "FROM" option is unnecessary and will be
> > a dead code. Because the syntaxer anyways would catch if FROM is
> > specified more than once, something like CREATE COLLATION mycoll1 FROM
> > FROM "C";.
>
> Hmm, it is possible to type CREATE COLLATION mycoll1 (FROM = "C", FROM
> = "POSIX") though. It will still be caught by the check at the bottom
> though, so I guess it's OK to skip the duplicate check in that case.
> Also, it's not a documented syntax, so it's unlikely to occur in
> practice anyway.
>
> > 2) I don't understand the difference between errorConflictingDefElem
> > and errorDuplicateDefElem.
> >
> > I personally don't like the new function errorDuplicateDefElem as it
> > doesn't add any value given the presence of pstate.
>
> Yeah, there was a lot of discussion on that other thread about using
> defel->defname in these kinds of errors, and that was still on my
> mind. In general there are a number of cases where defel->defname
> isn't quite right, because it doesn't match the user-entered text,
> though in this case it always does. You're right though, it's a bit
> redundant with the position indicator pointing to the offending
> option, so it's probably not worth the effort to include it here when
> we don't anywhere else. That makes the patch much simpler, and
> consistent with option-checking elsewhere -- v5 attached (which is now
> much more like your v3).

Thanks. The v5 patch LGTM.

Comment on errorConflictingDefElem:
I think that the message in errorConflictingDefElem should say
<<option \"%s\'' specified more than once>>. I'm not sure why it
wasn't done. Almost, all the cases where errorConflictingDefElem is
called from, def->defname would give the correct user specified option
name right, as errorConflictingDefElem called in if
(strcmp(def->defname, "foo") == 0) clause.

Is there any location the function errorConflictingDefElem gets called
when def->defname isn't a name that's specified by the user? Please
point me to that location. If there's a scenario, then the function
can be something like below:
void
errorConflictingDefElem(DefElem *defel, ParseState *pstate, bool
show_option_name)
{
    if (show_option_name)
        ereport(ERROR,
                errcode(ERRCODE_SYNTAX_ERROR),
                errmsg("option \"%s\" specified more than once",
defel->defname),
                pstate ? parser_errposition(pstate, defel->location) : 0);
    else
        ereport(ERROR,
                errcode(ERRCODE_SYNTAX_ERROR),
                errmsg("conflicting or redundant options"),
                pstate ? parser_errposition(pstate, defel->location) : 0);
}

Regards,
Bharath Rupireddy.



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)
Next
From: Gilles Darold
Date:
Subject: Re: [PATCH] Hooks at XactCommand level