Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT |
Дата | |
Msg-id | CAB7nPqS2gYpxS2yjOgaq58YA+GG-je6mi8LBhdOvWyCV64_ovw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT
|
Список | pgsql-hackers |
On Sun, Jun 4, 2017 at 7:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm unsure whether to back-patch or not; the main argument for not doing > so is that if any extensions are calling DefineIndex() directly, this > would be an API break for them. Given what a weird case this is, I'm not > sure it's worth that. Knowing that it has taken 20 years to get a report for this problem, It seems to me that one report does not win against the risk of destabilizing extensions that would surprisingly break after a minor update. > A possible end-run around the API objection would be to not add an extra > argument to DefineIndex() in the back branches, but to use !is_alter_table > as the control condition. That would work for the core callers, although > we might need a special case for bootstrap mode. On the other hand, > thinking again about hypothetical third-party callers, it's possible that > that's not the right answer for them, in which case they'd be really in > trouble. So I'm not that much in love with that answer. Yes, that's not worth the trouble I think for back-branches. The patch looks good to me, could you add a regression test? This could be used later on as a basis for other DDL commands if somebody looks at this problem for the other ones. -- Michael
В списке pgsql-hackers по дате отправления: