elein <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org