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