Re: [HACKERS] UPDATE of partition key
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] UPDATE of partition key |
Дата | |
Msg-id | CAA4eK1J_RYCtrUmMDygwRV5oAEE-hOkkLcQUaMq2dHA_vAd9FQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] UPDATE of partition key (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [HACKERS] UPDATE of partition key
|
Список | pgsql-hackers |
On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > On Wed, May 17, 2017 at 3:15 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >>> Earlier I thought that option1 is better but later I think that this >>> can complicate the situation as we are firing first BR update then BR >>> delete and can change the row multiple time and defining such >>> behaviour can be complicated. >>> >> >> If we have to go by this theory, then the option you have preferred >> will still execute BR triggers for both delete and insert, so input >> row can still be changed twice. > > Yeah, right as per my theory above Option3 have the same problem. > > But after putting some more thought I realised that only for "Before > Update" or the "Before Insert" trigger row can be changed. > Before Row Delete triggers can suppress the delete operation itself which is kind of unintended in this case. I think without the user being aware it doesn't seem advisable to execute multiple BR triggers. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: