Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Дата
Msg-id 1295808196.1803.20420.camel@ebony
обсуждение исходный текст
Ответ на Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Ответы Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

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.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: REVIEW: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Only show pg_stat_replication details to superusers