On Wed, Nov 25, 2009 at 9:21 AM, Emmanuel Cecchet <m...@asterdata.com> wrote: > Robert Haas wrote: >> On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing <ha...@2ndquadrant.com> >> wrote: >>> >>> I'd propose that triggers on both parent table and selected child are >>> executed. >> >> I was thinking we should make the partitioning decision FIRST, before >> any triggers are fired, and then fire only those triggers relevant to >> the selected partition. If the BEFORE triggers on the partition >> modify the tuple in a way that makes it incompatible with the table >> constraints on that partition, the insert (or update) fails. >> >> Firing triggers on more than one table is pretty substantially >> incompatible with what we do elsewhere and I'm not clear what we get >> in exchange. What is the use case for this? > > I don't have a use case for this but I was puzzled with that when I had to > implement trigger support in COPY with partitioning. > I came to the same conclusion as you and made the operation fail if the > trigger was trying to move the tuple to another partition. However, I had a > problem with after row triggers that I had to call synchronously to be able > to detect the change. We will need something to tell us that an after row > trigger did not mess with the routing decision.
*scratches head* I'm confused. Only a BEFORE ROW trigger can possibly change anything... the return value of an AFTER ROW trigger is ignored. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
