[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    [HACKERS] Tables cannot have INSTEAD OF triggers
From:       Aliouii Ali <aliouii.ali () aol ! fr>
Date:       2015-03-31 12:49:45
Message-ID: 14c6fe168a9-1012-10e1b () webprd-a87 ! mail ! aol ! com
[Download RAW message or body]

hi all, 
back in 2011(http://www.postgresql.org/message-id/1305138588.8811.3.camel@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 ..


[Attachment #3 (text/html)]

<font color='black' size='2' face='arial'>
<div><font style="background-color: transparent;">hi all, </font></div>

<div>back in 2011(<a \
href="http://www.postgresql.org/message-id/1305138588.8811.3.camel@vanquo.pezone.net"> \
http://www.postgresql.org/message-id/1305138588.8811.3.camel@vanquo.pezone.net</a>), \
an question the same as this one was asked </div>

<div>the anwser was : </div>

<div>&nbsp;</div>

<div>I think they're very useful on views, but I<br>
couldn't think of a use-case for having them on tables. ISTM that<br>
anything an INSTEAD OF trigger on a table could do, could equally well<br>
be done in a BEFORE trigger.<br>
</div>

<div>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)&nbsp; 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&nbsp;jobs done</div>

<div>&nbsp;</div>

<div>and about :</div>

<div>If we did support INSTEAD OF triggers on tables, we would also need to<br>
decide how they interact with BEFORE/AFTER triggers - do they fire in<br>
between them, or do they replace them? I could see arguments for<br>
either behaviour.</div>

<div>&nbsp;</div>

<div>we already have the three trigger defined on view. the same behavior goes on \
table.</div>

<div>in the doc <a href="http://www.postgresql.org/docs/9.4/static/trigger-definition. \
html">http://www.postgresql.org/docs/9.4/static/trigger-definition.html</a>&nbsp;it \
mention that if a one trigger return a no null value then fire the next one else \
ignore </div>

<div>&nbsp;</div>

<div>some guys&nbsp; on postgresql irc channel says that it is easy to implement :) . \
so it will be good to have&nbsp; it in the next minor or major release ..</div>

<div><br>
&nbsp;</div>
</font>



[prev in list] [next in list] [prev in thread] [next in thread]