I have fixed the problem with the keys being in different order and the
problem of missing unique constraints.
Tom Lane writes:
> >> Which there may not be (the backend code for creating an FK checks for a
> >> matching unique index, quite a different animal).
>
> > I think that should be changed.
>
> No, because that would entail a genuine loss of capability: FK
> constraints couldn't be built using indexes that were made by CREATE
> UNIQUE INDEX rather than through the unique/pk constraint syntax.
> In particular this would mean that non-btree indexes could not be used.
But that means the deficiency is elsewhere, namely that you cannot build
non-btree indexes for primary key or unique constraints.
> (Yes, I know that as of today we don't have UNIQUE support in any of the
> non-btree index types, but that will change. IIRC Neil Conway has
> already been working on unique hashes, and I'm sure GIST will support it
> eventually as well.)
Isn't the whole unique index thing a dead end anyway? How are we ever
going to get deferrable unique constraints that way?
--
Peter Eisentraut peter_e@gmx.net