Re: Foreign key validation failure in 18beta1
От | Amul Sul |
---|---|
Тема | Re: Foreign key validation failure in 18beta1 |
Дата | |
Msg-id | CAAJ_b95vZTBeN10J6bTRTAVf6eRTFWZMD3C-OFoaUNz15gahvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Foreign key validation failure in 18beta1 (jian he <jian.universality@gmail.com>) |
Ответы |
Re: Foreign key validation failure in 18beta1
|
Список | pgsql-hackers |
On Thu, May 29, 2025 at 5:57 PM jian he <jian.universality@gmail.com> wrote: > > On Thu, May 29, 2025 at 8:12 PM Amul Sul <sulamul@gmail.com> wrote: > > > > > >> > [...] > > > The attached *draft* patch is based on your idea. > > > > > > The idea is that we only need to conditionally do > > > ``tab->constraints = lappend(tab->constraints, newcon);`` within > > > QueueFKConstraintValidation. > > > but the catalog update needs to be done recursively. > > > > I like this approach, but I don’t think the flag name "recursing" is > > appropriate, as the flag is meant to indicate whether we want to > > enqueue constraints for validation or not. > > > > Later, I came up with "need_validate", but it seems "queueValidation" > is better. > > I just realized we have the same problem with ALTER FOREIGN KEY ENFORCED. > for example: Yeah, I think adding a "currcon->confrelid == pkrelid" check before enqueueing validation in ATExecAlterConstrEnforceability() would address the issue, though I still need to test it thoroughly. Regards, Amul
В списке pgsql-hackers по дате отправления: