On Friday, September 6, 2002, at 08:52 , Stephan Szabo wrote:
>
> On Fri, 6 Sep 2002, Joel Rodrigues wrote:
>
>> Thanks for the info & hints guys. Sad really that the most
>> obvious construct does not work. So, though I can get away with
>> skipping the REFERENCES bit by using a VIEW. I'd still like to
>> have some sort of referential integrity checking. I'm puzzled
>> about how to achieve this. I thought I'd do a CHECK with a
>> subquery expression, but, "Currently, CHECK expressions cannot
>> contain subselects". And it's not even on the TODO list. Foiled
>> again !
>>
>>
>> A bit of searching on Google Groups reveals that at least a few
>> people have attempted to use "...integer[] references...". Hate
>> to use the "o" word again, but it is really such an obvious
>> construct both in it's conception and (optimistic)
>> implementation.
>
> Not really. There are some performance issues and such surrounding
> it. Arrays are positional and not multisets, so you get some
> wierdness at the conversion.
>
> For example:
> I have (3,4) in an array. I update it to (4). For foreign
> key purposes, is this effectively a delete of 3 (ie no
> check required) or a delete of 4 and a change of 3->4.
> If the array has 100 elements and I remove the first one,
> do I do 99 foreign key checks or do I try to determine
> that's all that happened. What if the rest of the elements
> were randomly assorted?
Hello Stephan, I understand what you're saying. I didn't see
that. Thanks. But would there be any problem with allowing
subselects within CHECK expressions ?
- Joel