Laurenz Albe <laurenz.albe@cybertec.at> writes:
> I think I see what you mean:
> CREATE TABLE temp (
> id bigint NOT NULL,
> valid tstzrange NOT NULL,
> CONSTRAINT temp_pkey PRIMARY KEY (id, valid WITHOUT OVERLAPS)
> );
[ Note that this example requires having installed btree_gist ]
> SELECT pg_get_indexdef('temp_pkey'::regclass);
> pg_get_indexdef
> ----------------------------------------------------------------------
> CREATE UNIQUE INDEX temp_pkey ON laurenz.temp USING gist (id, valid)
> That CREATE INDEX statement won't work.
Yes. That is a pretty serious oversight in fc0438b4e. But I don't
think your patch proposal of just suppressing the UNIQUE keyword in
pg_get_indexdef_worker improves matters, because that presumably would
result in building an index that doesn't enforce the constraint.
I have not looked at the WITHOUT OVERLAPS patch, but if the mechanism
underlying that is just to set pg_index.indisunique, then it seems
like a reasonable answer here is to allow this syntax. The question
we have is how CREATE INDEX can know that UNIQUE is supported for
index types other than btrees.
regards, tom lane
