Re: Dropping behavior for unique CONSTRAINTs - Mailing list pgsql-general

From Ron
Subject Re: Dropping behavior for unique CONSTRAINTs
Date
Msg-id 0d0e4771-a1f2-f883-a983-4a4aee1bce9b@gmail.com
Whole thread Raw
In response to Re: Dropping behavior for unique CONSTRAINTs  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: Dropping behavior for unique CONSTRAINTs  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
List pgsql-general
On 3/4/23 02:03, Peter J. Holzer wrote:
[snip]
> So your plan is to create a unique constraint (backed by a unique
> index) and then to drop the index and keep the constraint?
>
> That doesn't work. A unique constraint can't exist without a (unique)
> index. Think about it: With a unique constraint PostgreSQL needs to
> check for every insert whether the value already exists in the table.
> Without an index this would mean a full table scan.

I cut my teeth on an RDBMS which didn't automagically create a backing 
index.  You had to do it yourself...

(Autocommit and the default transaction mode not being SERIALIZABLE were 
also a shock when I started using other systems.)

-- 
Born in Arizona, moved to Babylonia.



pgsql-general by date:

Previous
From: "Peter J. Holzer"
Date:
Subject: Re: Dropping behavior for unique CONSTRAINTs
Next
From: Alban Hertroys
Date:
Subject: Re: DISTINCT *and* ORDER BY in aggregate functions on expressions(!)y