I wrote:
> 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.
On second thought, not really, because it'd preclude ever supporting
"normal" unique indexes with GiST. Really the only thing I can
think of that isn't a complete violation of pg_get_indexdef's contract
to produce a correct representation of the index is for it to emit
an ALTER TABLE ADD CONSTRAINT command to represent these indexes.
Which seems like kind of a mess, not only because it will likely
require a deal of extra code in ruleutils, but because it will likely
break calling applications that aren't expecting such syntax.
I wonder how hard it would be to extend CREATE INDEX so that it
could produce a non-phony representation of such indexes, with the
&&-semantics columns clearly distinguished from the =-semantics ones.
Is including an opclass name sufficient, or is there some additional
secret sauce for the temporal columns?
fc0438b4e could perhaps have spent a bit longer in the oven.
regards, tom lane
