Re: Bug in the information_schema.referential_constraints

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(at)gmx(dot)net