Stephan Szabo wrote:
> Hmm, don't know why it's not in changelog, but the spec requires that
> the target fields of a foreign key constraint are themselves constrained
> by a unique or primary key constraint.
maybe its time for me to go and re-read the changelog with a fine tooth
comb (it has been known for me to be blind to the obvious before and
if this is the case then i more than apologise :)
> 7.0 didn't actually check this,
> but 7.1 does. The reason for this is because while 7.0 would let you
> specify such a constraint, it wouldn't really work entirely properly
> if the field wasn't actually unique. You'll need a unique constraint
> on client.client_id.
hhrrm. the only problem with -that- is that client_id by itself is not
unique, but in conjunction with order_id it is. order_id is wholly
unique. maybe i should jst drop the foreign key on client_id then,
although i did want to use referential integrity on the client_id on
an insert.
although now i think about this, the criteria for having the changes
on client_id cascading are totally gone and i could (read will) jst
use a 'references' column.
in short, thank you, i have jst figured out what an idiot i have been
(again i hear you all say ;)
many thanks and good work on postrgresql 7.1, it seems to be quite
a bit quicker (and praise the lord for outer joins =)
stefs