The thing that most approaches to this have fallen down on is triggers ---
that is, a trigger function might access columns mentioned nowhere in the
SQL text. (See 8b6da83d1 for a recent example :-() If you have a plan
for dealing with that, then ...
Well, if we had a trigger language that compiled to <something> at creation time, and that trigger didn't do any dynamic/eval code, we could store which attributes and rels were touched inside the trigger.
I'm not sure if that trigger language would be sql, plpgsql with a "compile" pragma, or maybe we exhume PSM, but it could have some side benefits:
1. This same issue haunts any attempts at refactoring triggers and referential integrity, so narrowing the scope of what a trigger touches will help there too
2. additional validity checks
3. (this is an even bigger stretch) possibly a chance to combine multiple triggers into one statement, or combine mutliple row-based triggers into a statement level trigger
Of course, this all falls apart with one dynamic SQL or one SELECT *, but it would be incentive for the users to refactor code to not do things that impede trigger optimization.