Re: Rejecting redundant options in Create Collation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Rejecting redundant options in Create Collation
Date: 2020-10-01 18:58:53
Message-ID: 1055272.1601578733@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> Currently, it's not an error for CREATE COLLATION to be invoked
> with options repeated several times. The last (rightmost) value is kept
> and the others are lost.
> ...
> I suggest the attached simple patch to raise an error when any of
> these options is specified multiple times.

Hmm ... I think that that is pretty standard behavior for a lot of
our utility commands. Trying something at random,

regression=# create operator <<< (leftarg = int, leftarg = int,
regression(# rightarg = int99, procedure = int4pl, rightarg = int);
CREATE OPERATOR

Note the lack of any comment on the flat-out-wrong first value
for rightarg :-(

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-10-01 19:12:44 buildfarm animal shoveler failing with "Illegal instruction"
Previous Message Daniel Verite 2020-10-01 18:46:53 Rejecting redundant options in Create Collation