Hmm... hiding/covering up schema changes by dynamic SQL is a two-edged sword.
Of course it reduces development effort for multiple development code lines to a certain degree.
On the other hand it makes the code a lot more complex which translates into less options to optimize queries or - like in this example - to use prepared statements.
Also, often a schema change doesn't come by itself and application logic that deals with the changed data needs to be added anyhow. And at that point you have a code split anyway.
So, as of now the recommendation from the developer guide to avoid dynamic SQL as far as possible holds true.
- Lars