In general you will get a better plan if you give the optimizer the option of flattening subselects so I doubt
in general using a plpgsql proc (or smarter subselect plan caching) is the right answer.
One of the most common way we end up with really bad plans
is that we have deeply nested views which exceed the count
of joins that the optimizer will consider for flattening.
It used to be GEQO_THRESHOLD/2 joins (6 I think) in <7.4 but they
added a seperate parameter for it in 7.4 --
from_collapse_limit = 8 (docs).
