Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> 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
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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Another problem is that the view will fail to list FK constraints at all
>> if it cannot identify a matching unique constraint.
> If you want information under those conditions, you're looking at the
> wrong view. table_constraint
Tom Lane writes:
> > AND con.contype = 'f'
> > AND con.confrelid = pkc.conrelid
>
> I think this is correct as far as it goes, but there are more problems.
Added.
> For one, I believe we also need to check the contype of the pkc row;
> otherwise matches against check constrai
[EMAIL PROTECTED] writes:
> The information_schema.referential_constraints retuns wrong data because
> there is an incomplete joining condition in the WHERE clause.
> [ these two conditions need to be added: ]
> AND con.contype = 'f'
> AND con.confrelid = pkc.conrelid
I think t
If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to [EMAIL PROTECTED]
To report any other bug, fill out the form below and e-mail it to
[EMAIL PROTECTED]
If you not only found the problem
