Re: "...integer[] references..." = error
От | Stephan Szabo |
---|---|
Тема | Re: "...integer[] references..." = error |
Дата | |
Msg-id | 20020907234641.C795-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: "...integer[] references..." = error (Joel Rodrigues <borgempath@Phreaker.net>) |
Список | pgsql-general |
On Sun, 8 Sep 2002, Joel Rodrigues wrote: > Forgot to comment: > > By "not really", you're referring to implementing the feature in > PostgreSQL, right ? Because what I referred to by "obvious" is > the need for this feature. And thinking about what you elaborate > on in your example, it seems to me that some restricted use of > such a construct (...integer[] references someID...) should be > included in the feature set. And yes I think the best and most > sensible solution would be to do in your example of a 100 > element array, would be to do 99 foreign key checks. I don't see > what the problem could be, other than a minuscule performance > hit perhaps depending on the machine you're running on. Mostly on implementation, however there are some specification level things as yet left unsaid dealing with arrays of arrays and multi-column keys. I'm not sure whether {{1,2},{3,4}} -> {2,1},{3,4} (two rows in the pk table, one in the fk) satisfies the constraint or not. As arrays not really, but since we're already treating an array as a multiset here, do we do that on both sides? Also, for multi-column foreign keys say a key like ({1,2},{3,4}) is that 2 combinations or 4? If 4 then the do all the checks become problematic as it does a number of checks equal to all of the array lengths (well, distinct values) multiplied together if there were multiple arrays and doing the more intelligent check (or deciding to do it for arrays over a certain length or something) could lower that greatly. It's likely to be done, probably not for a few versions as for many cases there is a workaround (using a details table) and there are bugs or at least misfeatures to kill first. > By the same token, CHECK could be allowed some restricted use of > subselects. But that item on the TODO list probably does deal > with this issue - I'll ask hackers about that. For some subset, you can get the general effect using trigger functions. You'd need to determine which actions on the tables involved could violate and write the appropriate functions.
В списке pgsql-general по дате отправления: