Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
От | Marko Tiikkaja |
---|---|
Тема | Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED |
Дата | |
Msg-id | 4D3C79E0.9050408@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT
ENFORCED
|
Список | pgsql-hackers |
On 1/23/2011 8:43 PM, Simon Riggs wrote: > On Sun, 2011-01-23 at 20:33 +0200, Marko Tiikkaja wrote: >> On 1/23/2011 8:23 PM, Simon Riggs wrote: >>> On Sun, 2011-01-23 at 19:50 +0200, Marko Tiikkaja wrote: >>>> Another problem I found is that psql doesn't indicate in any way that a >>>> FOREIGN KEY constraint is not validated yet. >>> >>> Should it? >>> What command do you think needs changing? >> >> \d table now only shows that there's a FOREIGN KEY, which might lead the >> user to think that there should not be any values that don't exist in >> the referenced table. > > Neither \d nor \di shows invalid indexes. What exactly are you referring to? An index with indisvalid=false looks like this in my psql: "fooindex" btree (a) INVALID And even if it didn't, I don't think we should be adding more deficiencies to psql. > Should we add validation for FKs when it is not there for indexes? > My feeling was no. > > Desirable for both? Yes, but not as part of this patch. > >>> There is no option to invoke this yet from pg_restore, which seems >>> likely to top the list of priorities. Would you agree? >> >> I don't understand what you mean with this. Could you be a bit more >> elaborate? > > The purpose of this patch is performance. pg_restore will be faster if > it uses this new feature, so I expect to add an option to reload data > without validating FKs. Ah. Right, that would make sense. Regards, Marko Tiikkaja
В списке pgsql-hackers по дате отправления: