Re: DELETE CASCADE

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: DELETE CASCADE
Дата
Msg-id 31b944f1-e38b-c277-c3e2-9841cade1e0d@enterprisedb.com
обсуждение исходный текст
Ответ на Re: DELETE CASCADE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
Список pgsql-hackers
On 03.06.21 23:47, David G. Johnston wrote:
> This behavior should require the same permissions as actually creating 
> an ON DELETE CASCADE FK on the cascaded-to tables.  i.e., Table Owner 
> role membership (the requirement for FK permissions can be assumed by 
> the presence of the existing FK constraint and being the table's owner).

You can create foreign keys if you have the REFERENCES privilege on the 
primary key table.  That's something this patch doesn't observe 
correctly: Normally, the owner of the foreign key table decides the 
cascade action, but with this patch, it's the primary key table owner.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Are we missing (void) when return value of fsm_set_and_search is ignored?