best performance for storing notifications in postgresql
There's nothing wrong with creating a dedicated table for notifications, along the route your example above is choosing to take. Whether you use triggers or handle managing it with calls from the application side is up to you and equally of merit as well.
Alternatively I was thinking similar to your last proposed solution, but by using a View as a way to centralize the different notification types and stay current in real-time. You would UNION ALL your different notification types and when you select from the View, you would likely order by the timestamp descending to show the latest notifications first.
The only other part you'd need to come up with is how to manage which notifications a user has already seen. For that you'd likely need a logging table of the notification's id and type, and had columns for the user's id and timestamp of when they viewed their notifications. Then in the View above you'd OUTER JOIN to this viewed notifications log, so you can have an additional column in it called isNew and you'd know which ones are new to the current user since the last time they looked at their notifications. At least this viewed notifications log table would be written to less frequently (only whenever a user looks at their notifications) than just a pure notifications table (every new instance of a notification), so it would be much transactionally lighter.