From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, boekewurm+postgres(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16767: Silent dropping of CONSTRAINT... UNIQUE |
Date: | 2020-12-12 22:18:15 |
Message-ID: | 03247a85-e663-159b-c825-4334aa479fd4@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2020-12-08 17:48, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>> I've just noticed that equivalent unique constraints that are specified in
>> the same statement only generate one constraint;
>
> Yeah, that's intentional. Per the source code comments:
>
> * Scan the index list and remove any redundant index specifications. This
> * can happen if, for instance, the user writes UNIQUE PRIMARY KEY. A
> * strict reading of SQL would suggest raising an error instead, but that
> * strikes me as too anal-retentive. - tgl 2001-02-14
It's nonetheless inconsistent that you can create redundant unique
constraints via ALTER TABLE, but doing it in CREATE TABLE results in
different behavior.
This all seems a bit dubious to me. We should either allow it or
prohibit it, not silently do something else in some cases.
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-12-14 16:22:58 | BUG #16772: Options --disable-triggers in combination with --superuser does not have the expected result |
Previous Message | PG Bug reporting form | 2020-12-11 11:34:47 | BUG #16771: Server process killed by signal 9, after recovery drop tablespace failed |