Hoe zorg je voor inzendingen met niet-overlappende tijdbereiken?

Je was op de goede weg. Maar de syntaxis voor uitsluitingsbeperkingen is iets anders.

Afhankelijk van de niet-openbaar gemaakte tabeldefinitie, moet u mogelijk de extensie installeren (extra module) btree_gist eerst. Een keer per db. Het is nodig voor mijn voorbeeld omdat de vereiste operatorklasse niet is geïnstalleerd voor het type integer standaard:

CREATE EXTENSION btree_gist;

Zie:

• PostgreSQL EXCLUDE USING-fout:gegevenstype integer heeft geen standaard operatorklasse
• Hoe te gebruiken ( install) dblink in PostgreSQL?

Dan:

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

Elke kolom moet worden vermeld met de bijbehorende operator.

En je hebt een bereiktype nodig . Je vermeldt aparte kolommen valid_from en valid_to . En je noemt ook tsrange en valid in de mislukte opdracht. Dat is verwarrend. Uitgaande van twee timestamp kolommen, een expressie-index met de expressie tsrange(valid_from, valid_to) zou het doen.

Gerelateerd:

• Voer dit uit bedrijfsuren opvragen in PostgreSQL
• Niet-overlappende, continue tijdstempelbereiken (tstzrange) voor openingstijden
• Postgresql 9.4-query wordt steeds langzamer wanneer u zich aansluit bij TSTZRANGE met &&
• Bewaar de dag van de week en tijd?

Meestal timestamptz (tstzrange ) moet worden gekozen boven timestamp (tsrange ). Zie:

• Tijd negeren zones samen in Rails en PostgreSQL

Misschien , zou een superieur ontwerp een een-op-veel-relatie zijn tussen uw registration tabel en 1-N items in een nieuw registration_range tafel. En enige logica om de momenteel geldige invoer te bepalen (voor een bepaald tijdstip). Hangt af van meer geheime informatie.