The information on this is, admittedly, hard to dig out of the primary docs but there also exists an INSTEAD OF trigger mode - so you can CREATE TRIGGER "actually_save_stuff" INSTEAD OF INSERT which will intercept an attempted insert on the table and write the rows elsewhere.

Generally I've found these useful in the short term for letting application logic continue to work blissfully ignorant to the fact that the "table" it is writing to has been moved, merged or refactored into a set of tables that the trigger will bridge logic over to. While in the long term I've found that the automatic logic covers the most common case, a view that's filtering out some rows for some reason (permissions - soft deletion) before presenting it to the application logic.