Re: "...integer[] references..." = error
От | Joel Rodrigues |
---|---|
Тема | Re: "...integer[] references..." = error |
Дата | |
Msg-id | 6F5CC610-C1C7-11D6-BB07-0005024EF27F@Phreaker.net обсуждение исходный текст |
Ответ на | Re: "...integer[] references..." = error (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Ответы |
Re: "...integer[] references..." = error
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: