On 2018/06/06 2:08, Alvaro Herrera wrote: > On 2018-Jun-05, Amit Langote wrote: > >> On 2018/06/05 16:41, Ashutosh Bapat wrote: >>> On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote >>> <langote_amit...@lab.ntt.co.jp> wrote: >>>> On 2018/06/05 1:25, Alvaro Herrera wrote: >>>>> In the meantime, my inclination is to fix the documentation to point out >>>>> that AFTER triggers are allowed but BEFORE triggers are not. >>>> >>>> Wasn't that already fixed by bcded2609ade6? > > Ah, yes, so it's already OK. > >>> Thought correct that suggestion is problematic for upgrades. Probably >>> users will create triggers using same function on all the partitions. >>> After the upgrade when we start supporting BEFORE TRIGGER on >>> partitioned table, the user will have to drop these triggers and >>> create one trigger on the partitioned table to have the trigger to be >>> applicable to the new partitions created. >> >> Hmm yes, maybe there is scope for rewording then. > > Reading that subsection in its entirety, I'm not sure how to do better > -- it's all about restrictions that currently exist and we think we > could do better in the future, with the exception of the one about an > UPDATE/DELETE not seeing the updated version after a row migrating to > another partition. One idea would be to split it into its own list of > issues; something like: > > "The following limitations apply, and might be lifted in the future: > - no way to create exclusion constraint > - foreign keys cannot refer to partitioned tables > - BEFORE row triggers are not supported > > The following caveat applies to partitioned tables: > - When an UPDATE causes a row to move ..." > > In other words, make a distinction of things we expect to change soon > (which might be too optimistic), vs. others we don't expect to change. > > Or we could leave it alone; any behavior change would be called out in > the future version's release notes anyway. This is what I propose.
That works for me. :) Thanks, Amit
