Question

I'm using "classic" time-based partitioning using triggers. I have found a need for a separate trigger, which runs on the original table.

CREATE TABLE twitter_interactions(...);
CREATE OR REPLACE FUNCTION insert_twitter_interactions ...;
CREATE TRIGGER insert_twitter_interactions_trig
  BEFORE INSERT OR UPDATE on twitter_interactions
  FOR EACH ROW EXECUTE PROCEDURE insert_twitter_interactions();

CREATE OR REPLACE FUNCTION maintain_data_pointers ...;
CREATE TRIGGER maintain_data_pointers_trig
  BEFORE INSERT OR UPDATE on twitter_interactions
  FOR EACH ROW EXECUTE PROCEDURE insert_twitter_interactions();

I haven't fully verified, but I suspect the partitioning logic runs before the maintain trigger, and since the row doesn't end up in the parent table, then the 2nd trigger never fires.

What happens if I want to run an AFTER INSERT OR UPDATE as well? Since the row doesn't make it into the original table, then I'm at a loss to implement the after logic.

Was it helpful?

Solution

I couldn't say it better than the manual does here:

If any BEFORE or INSTEAD OF trigger returns NULL, the operation is abandoned for that row and subsequent triggers are not fired (for that row).

Neither the (alphabetically) later triggers on the same event nor any AFTER triggers will fire, if the BEFORE trigger cancels.

OTHER TIPS

PostgreSQL executes the triggers in alphabetical order by name. So make sure to use names that get them in the order you want. From the docs

SQL specifies that multiple triggers should be fired in time-of-creation order. PostgreSQL uses name order, which was judged to be more convenient.

BTW your SQL creates the same trigger twice.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top