Vous étiez sur la bonne voie. Mais la syntaxe pour les contraintes d'exclusion est légèrement différent.
Selon la définition de table non divulguée, vous devrez peut-être installer l'extension
(module supplémentaire) btree_gist première. Une fois par db. C'est nécessaire pour mon exemple car la classe d'opérateur requise n'est pas installée pour le type integer par défaut :
CREATE EXTENSION btree_gist;
Voir :
- Erreur PostgreSQL EXCLUDE USING :le type de données entier n'a pas de classe d'opérateur par défaut
- Comment utiliser ( install) dblink dans PostgreSQL ?
Ensuite :
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 &&)
);Chaque colonne doit être répertoriée avec son opérateur respectif.
Et vous avez besoin d'un type de plage . Vous mentionnez des colonnes séparées valid_from et valid_to . Et vous mentionnez également tsrange et valid dans la commande ayant échoué. C'est déroutant. En supposant deux timestamp colonnes, un index d'expression avec l'expression tsrange(valid_from, valid_to) le ferait.
Connexe :
- Effectuez ceci requête d'heures de fonctionnement dans PostgreSQL
- Plages d'horodatage continu sans chevauchement (tstzrange) pour les heures d'ouverture
- La requête Postgresql 9.4 devient progressivement plus lente en rejoignant TSTZRANGE avec &&
- Stocker le jour de la semaine et heure ?
Typiquement, timestamptz (tstzrange ) doit être choisi sur timestamp (tsrange ). Voir :
Peut-être , une conception supérieure serait une relation un-à-plusieurs entre votre registration table et entrées 1-N dans un nouveau registration_range table. Et une logique pour déterminer l'entrée actuellement valide (pour un moment donné). Dépend d'autres informations non divulguées.
