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.ga15...@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
signature.asc
Description: PGP signature
