I don't like TFA's TRIGGER using their aggregate function for the FSM because they are not ordering the events by time, but also because you just don't need the

I don't like TFA's TRIGGER using their aggregate function for the FSM because they are not ordering the events by time, but also because you just don't need the complexity of reviewing every event for an order every time there is a new event for the same order if you can just assume that all events arrive in chronological order and therefore the FOR EACH ROW trigger fires in chronological order. And if the events don't arrive (or are inserted) in chronological order then you need a FOR EACH STATEMENT trigger instead of a FOR EACH ROW trigger. Besides even as coded in TFA there is very much an in-built assumption that order_events inserts happen in chronological order anyways, so you just don't need to use the aggregate function in that trigger. The aggregate function is pretty neat and useful though, but every time you use you have to order input events by time, so the query of how many orders are in each possible state on any given day is incorrect. Also, if you have a column to store the current/newest state of each order then I believe you can use plain SQL for the trigger function instead of PlPgSQL since you can then rely on a CHECK() to raise an exception when the new state would be 'error'. (I bet TFA is looking for comments like these since as you can see at the bottom of TFA they are hiring.)