Re: Dropping behavior for unique CONSTRAINTs

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: Dropping behavior for unique CONSTRAINTs
Дата
Msg-id 20230304115152.df5pmrgny7z5ogkm@hjp.at
обсуждение исходный текст
Ответ на Re: Dropping behavior for unique CONSTRAINTs  (Ron <ronljohnsonjr@gmail.com>)
Ответы Re: Dropping behavior for unique CONSTRAINTs  (Ron <ronljohnsonjr@gmail.com>)
Список pgsql-general
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?

I'm pretty sure Oracle did that automatically when I first used it
(version 8.0.5). Not sure about MySQL, but if it didn't have an index it
probably didn't enfocre the constraint either (it definitely didn't
enforce foreign key constraints).

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 ...

        hp

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

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Alban Hertroys
Дата:
Сообщение: Re: DISTINCT *and* ORDER BY in aggregate functions on expressions(!)y
Следующее
От: Raivo Rebane
Дата:
Сообщение: shp2pgsql error under windows