Hur säkerställer man poster med icke-överlappande tidsintervall?

Du var på rätt spår. Men syntaxen för uteslutningsrestriktioner är något annorlunda.

Beroende på den ej avslöjade tabelldefinitionen kan du behöva installera tillägget (ytterligare modul) btree_gist först. En gång per db. Det behövs för mitt exempel eftersom den nödvändiga operatörsklassen inte är installerad för typen integer som standard:

CREATE EXTENSION btree_gist;

Se:

• PostgreSQL EXCLUDE USING-fel:Datatyp heltal har ingen standardoperatorklass
• Hur man använder ( installera) dblink i PostgreSQL?

Sedan:

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 &&)
);

Varje kolumn måste listas med sin respektive operator.

Och du behöver en intervalltyp . Du nämner separata kolumner valid_from och valid_to . Och du nämner också tsrange och valid i det misslyckade kommandot. Det är förvirrande. Antag två timestamp kolumner, ett uttrycksindex med uttrycket tsrange(valid_from, valid_to) skulle göra det.

Relaterat:

• Utför detta driftstimmarsfråga i PostgreSQL
• Icke-överlappande, kontinuerliga tidsstämpelintervall (tstzrange) för öppettider
• Postgresql 9.4-frågan blir gradvis långsammare när man går med i TSTZRANGE med &&
• Lagra veckodag och tid?

Vanligtvis timestamptz (tstzrange ) bör väljas framför timestamp (tsrange ). Se:

• Ignorerar tid zoner helt och hållet i Rails och PostgreSQL

Kanske , skulle en överlägsen design vara en en-till-många-relation mellan din registration tabell och 1-N-poster i ett nytt registration_range tabell. Och lite logik för att bestämma den för närvarande giltiga posten (för en given tidpunkt). Beror på mer hemlig information.