Hi, I haven't really been following this thread, but after playing around a bit with the feature I feel there are new gaps in error messages. I also think there are gaps in the functionality regarding the (lack of) support for CREATE UNIQUE INDEX, and attaching these indexes to constraints.
pg=# CREATE TABLE temporal_testing ( pg(# id bigint NOT NULL pg(# generated always as identity, pg(# valid_during tstzrange pg(# ); CREATE TABLE pg=# ALTER TABLE temporal_testing pg-# ADD CONSTRAINT temp_unique UNIQUE (id, valid_during WITHOUT OVERLAPS); ALTER TABLE pg=# \d+ temp_unique Index "public.temp_unique" Column | Type | Key? | Definition | Storage | Stats target --------------+-------------+------+--------------+----------+-------------- id | gbtreekey16 | yes | id | plain | valid_during | tstzrange | yes | valid_during | extended | unique, gist, for table "public.temporal_testing" -- ^^ note the "unique, gist" pg=# CREATE UNIQUE INDEX ON temporal_testing USING gist (id, valid_during); ERROR: access method "gist" does not support unique indexes Here we obviously have a unique GIST index in the catalogs, but they're "not supported" by GIST when we try to create such index ourselves (!). Either the error message needs updating, or we need to have a facility to actually support creating these unique indexes outside constraints. Additionally, because I can't create my own non-constraint-backing unique GIST indexes, I can't pre-create my unique constraints CONCURRENTLY as one could do for the non-temporal case: UNIQUE constraints hold ownership of the index and would drop the index if the constraint is dropped, too, and don't support a CONCURRENTLY modifier, nor an INVALID modifier. This means temporal unique constraints have much less administrative wiggle room than normal unique constraints, and I think that's not great. Kind regards, Matthias van de Meent.