Re: Dropping behavior for unique CONSTRAINTs
От | Ron |
---|---|
Тема | Re: Dropping behavior for unique CONSTRAINTs |
Дата | |
Msg-id | 4933fde5-f139-0d4d-13ed-b4ab96ffb537@gmail.com обсуждение исходный текст |
Ответ на | Re: Dropping behavior for unique CONSTRAINTs ("Peter J. Holzer" <hjp-pgsql@hjp.at>) |
Список | pgsql-general |
On 3/4/23 05:51, Peter J. Holzer wrote: > On 2023-03-04 02:34:02 -0600, Ron wrote: >> 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... > Just curious: Which RDBMS was that? Rdb/VMS (the DEC product for OpenVMS, which has been owned by Oracle for the past 25 years). > Speaking of foreign key constraints: Neither Oracle nor PostgreSQL > automatically add an index on a foreign key. That bit me hard back in > the day ... Us too. (Well, the developer, from before I arrived.) -- Born in Arizona, moved to Babylonia.
В списке pgsql-general по дате отправления: