Dropping behavior for unique CONSTRAINTs - Mailing list pgsql-general

From Conner Bean
Subject Dropping behavior for unique CONSTRAINTs
Date
Msg-id 3d7d49f0-7eef-4d6d-8dc3-1993ba2fc2cb@me.com
Whole thread Raw
Responses Re: Dropping behavior for unique CONSTRAINTs  (David Rowley <dgrowleyml@gmail.com>)
Re: Dropping behavior for unique CONSTRAINTs  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
List pgsql-general
Hi folks,

I'm curious if there are any docs supporting the functionality behind dropping unique constraints. For context, I am interested in enforcing uniqueness on a column. This table is heavily used, and I plan on dropping the constraint in the future. I wanted to avoid using a unique index since dropping them requires an exclusive lock and cannot be done concurrently. My thought was to then use a unique constraint, since I've read unofficial docs[0] that say these can be dropped safely with no lock.

However, since a unique index would be the backing index to the unique constraint, I'm curious how this would work in practice (or if it even does!). Specifically if my theory of: "I can use a unique constraint to avoid obtaining an exclusive lock on my table" actually works.

Thanks for any and all information, it's greatly appreciated, and apologies if I missed any existing documentation.

Best, 
CSB



pgsql-general by date:

Previous
From: cen
Date:
Subject: Re: Postgres undeterministically uses a bad plan, how to convince it otherwise?
Next
From: Ron
Date:
Subject: Converting row elements into a arrays?