| From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Dropping behavior for unique CONSTRAINTs |
| Date: | 2023-03-04 08:34:02 |
| Message-ID: | 0d0e4771-a1f2-f883-a983-4a4aee1bce9b@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alban Hertroys | 2023-03-04 10:48:24 | Re: DISTINCT *and* ORDER BY in aggregate functions on expressions(!)y |
| Previous Message | Peter J. Holzer | 2023-03-04 08:09:40 | Re: Dropping behavior for unique CONSTRAINTs |