hi all,
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.
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 ..