Re: Dropping behavior for unique CONSTRAINTs

On 2023-03-04 13:50:28 +1300, David Rowley wrote:
> On Sat, 4 Mar 2023 at 10:55, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
> > On 3/3/23 04:54, David Rowley wrote:
> > If you have a look at
> > https://www.postgresql.org/docs/15/sql-dropindex.html check out the
> > CONCURRENTLY option. That option allows an index to be dropped without
> > blocking concurrent reads and writes to the table. It seems like just
> > having a unique index without the constraint is likely your best bet
> > if you can't afford to block any traffic for the brief moment it would
> > take to drop the constraint.
> >
> >
> > That doc page says this about CONCURRENTLY:
> > "
> > There are several caveats to be aware of when using this option.
> > Only one index name can be specified, and the CASCADE option is not
> > supported. (Thus, an index that supports a UNIQUE or PRIMARY KEY
> > constraint cannot be dropped this way.)
> > "
>
> I'm not sure which one of these you think applies to the
> recommendation I mentioned

The OP asked specifically about dropping the index backing a unique
constraint, so Ron is pointing out that CONCURRENTLY cannot be used for
that purpose.

(I realize that your idea is not to create the constraint in the first
place.)

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"