elein <elein@varlena.com> writes:
> ... What I'm saying is that the opclass needs to be
> an option to PRIMARY KEY and FOREIGN KEY--
PRIMARY KEY and UNIQUE, you mean.
This was brought up before, but I remain less than excited about it.
You can get essentially the same functionality by doing a CREATE UNIQUE
INDEX command, so allowing it as part of the PK/UNIQUE syntax is little
more than syntactic sugar. I'm concerned that wedging opclass names
into that syntax could come back to haunt us some day --- eg, if SQL2009
decides to put their own kind of option into the same syntactic spot.
> The case in point is a subtype (domain) with a BTREE operator class.
> I can of course create a separate unique index, however, if I use the
> PRIMARY KEY syntax the op class of the data type is not recognized.
Hm, does CREATE INDEX work without explicitly specifying the opclass?
I suspect your complaint really stems from overeager getBaseType() calls
in the index definition code, which is maybe fixable without having to
get into syntactic extensions.
regards, tom lane