hi all, back in 2011(http://www.postgresql.org/message-id/1305138588.8811.3.ca...@vanquo.pezone.net), an question the same as this one was asked the anwser was :
I think they're very useful on views, but I couldn't think of a use-case for having them on tables. ISTM that anything an INSTEAD OF trigger on a table could do, could equally well be done in a BEFORE trigger. no not really there is a use-case : in partitioned table ( instead of defining before trigger on the master table that return null as the doc states, it will be good things to have instead of trigger that return NEW) so that query like insert/update ... .. RETURNING will be handdy and gain some performance, otherwise we will have to do an insert and select to get the same jobs done and about : If we did support INSTEAD OF triggers on tables, we would also need to decide how they interact with BEFORE/AFTER triggers - do they fire in between them, or do they replace them? I could see arguments for either behaviour. we already have the three trigger defined on view. the same behavior goes on table. in the doc http://www.postgresql.org/docs/9.4/static/trigger-definition.html it mention that if a one trigger return a no null value then fire the next one else ignore some guys on postgresql irc channel says that it is easy to implement :) . so it will be good to have it in the next minor or major release ..
