Jak zapewnić wpisy o nienakładających się przedziałach czasowych?

Byłeś na dobrej drodze. Ale składnia ograniczeń wykluczenia jest nieco inny.

W zależności od nieujawnionej definicji tabeli może być konieczne zainstalowanie rozszerzenia (dodatkowy moduł) btree_gist pierwszy. Raz na db. Jest to potrzebne w moim przykładzie, ponieważ wymagana klasa operatora nie jest zainstalowana dla typu integer domyślnie:

CREATE EXTENSION btree_gist;

Zobacz:

• Błąd PostgreSQL EXCLUDE USING:typ danych nie ma domyślnej klasy operatora
• Jak używać ( zainstalować) dblink w PostgreSQL?

Następnie:

CREATE TABLE registration  (
  tbl_id integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY
, col_a  integer NOT NULL
, col_b  integer NOT NULL
, valid_from timestamp
, valid_to   timestamp
, CONSTRAINT no_overlap
    EXCLUDE USING gist (col_a with =, col_b with =, tsrange(valid_from, valid_to) WITH &&)
);

Każda kolumna musi być wymieniona z odpowiednim operatorem.

I potrzebujesz typu zakresu . Wspominasz oddzielne kolumny valid_from i valid_to . Wspominasz również o tsrange i valid w nieudanym poleceniu. To mylące. Zakładając dwa timestamp kolumny, indeks wyrażenia z wyrażeniem tsrange(valid_from, valid_to) zrobiłby to.

Powiązane:

• Wykonaj to godziny pracy zapytania w PostgreSQL
• Nienakładające się, ciągłe zakresy sygnatur czasowych (tstzrange) dla godzin otwarcia
• Kwerendy Postgresql 9.4 stają się coraz wolniejsze podczas dołączania do TSTZRANGE za pomocą &&
• Przechowuj dzień tygodnia i godzinę?

Zazwyczaj timestamptz (tstzrange ) należy wybrać zamiast timestamp (tsrange ). Zobacz:

• Ignorowanie czasu strefy łącznie w Railsach i PostgreSQL

Może , lepszym projektem byłaby relacja jeden-do-wielu między Twoją registration tabela i 1-N wpisów w nowym registration_range stół. I trochę logiki do określenia aktualnie ważnego wpisu (dla dowolnego punktu w czasie). Zależy od bardziej nieujawnionych informacji.