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
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 |