Re: Rejecting redundant options in Create Collation

On Thu, Oct 01, 2020 at 02:58:53PM -0400, Tom Lane wrote:
> Hmm ... I think that that is pretty standard behavior for a lot of
> our utility commands. Trying something at random,

The behavior handling is a bit inconsistent. For example EXPLAIN and
VACUUM don't do that, because their parenthesized grammar got
introduced after the flavor that handles options as separate items in
the query, so redundant options was not something possible with only
the original grammar.

> I can see the argument for complaining about repeated options rather
> than letting this pass. But shouldn't we try to make it uniform
> instead of letting different commands have different policies?

Consistency would be a good thing. There is a very recent discussion
in this area for COPY actually, where the option redundancy is handled
incorrectly:
https://www.postgresql.org/message-id/20200929072433.GA15570@paquier.xyz

The argument goes in both ways. If we handle redundant options, I
would also suspect that users complain back about the lack of error
checks with stupid input values, but I'd like to think that it can
also be beneficial in some cases. Now, if we don't handle redundant
options, that's less code, less risk to introduce semi-broken
behaviors like what COPY has done for years and a bit less work for
new translators, but the last point is not really an issue as we have
a generic error message here. From the point of view of a code
maintainer, not handling redundant options at all is more appealing
IMO in the long-term. From the user perspective, there are benefits
and disadvantages with both. So, at the end, it seems to me that not
doing it anymore for any commands would have more benefits in the
long-term than doing it.
--
Michael