Problem in AlterTableAddConstraint?
От | Philip Warner |
---|---|
Тема | Problem in AlterTableAddConstraint? |
Дата | |
Msg-id | 3.0.5.32.20001129024911.02c4e6d0@mail.rhyme.com.au обсуждение исходный текст |
Ответы |
Re: Problem in AlterTableAddConstraint?
Re: Problem in AlterTableAddConstraint? |
Список | pgsql-hackers |
Browsing through backend/commands/command.c I noticed the following code: if (indexStruct->indisunique) { List *attrl; /* go through the fkconstraint->pk_attrs list */ foreach(attrl, fkconstraint->pk_attrs) { Ident*attr=lfirst(attrl); found = false; for (i = 0; i < INDEX_MAX_KEYS && indexStruct->indkey[i] !=0; i++) { int pkattno = indexStruct->indkey[i]; if (pkattno>0) { char *name = NameStr(rel_attrs[pkattno-1]->attname); if (strcmp(name, attr->name)==0) { found = true; break; } } } if (!found) break; } } which is (I think) supposed to be checking for a unique index on the FK fields in the referenced table. Unfortunately, my reading of this code suggests it is doing the following: for each column in the FK see if we can find the column in the index if not, then die next FK column The problem with this is that it needs to ensure a 1:1 match between columns for the UNIQUE constraint requirement to be satisfied...I think. To give an example, create table c2(f1 integer, f2 integer, unique(f1,f2)); create table c1(f1 integer, f2 integer, foreign key(f1) references c2(f1)); is allowed with current sources. I'd guess that adding code to ensure the column lists are the same size would fix the problem. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: