Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Simon Riggs wrote:
>>> I notice that we allow commands such as
>>> SET TRANSACTION read only read write read only;
>>> BEGIN TRANSACTION read only read only read only;
> My own feeling is that the second example is okay but the first should
> be rejected, since (a) it's quite unclear what the user wants, and (b)
> the ensuing behavior would be determined by implementation artifacts
> like which order we processed the options in.
I think this might be best solved by providing a common function that
checks a DefElem list for duplicates. This could be used in a number of
other places as well (grep for "conflicting or redundant options").