Re: Foreign keys for non-default datatypes

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