Re: BUG #16767: Silent dropping of CONSTRAINT... UNIQUE

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.

In response to

Browse pgsql-bugs by date

  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