@cebe made three arguments:

2. Users are competent and don't need this help from the framework.
1. Consistency with what other `CDbCommandBuilder`s do reduces the chance of surprising a user accustomed to that behavior (and hence the rate of bug reports pointing out the inconsistency)
3. Performance.

On 1. I can say with authority that I, for one, am incompetent. I have never kept a list of a DB's reserved words to hand when I compose queries or SQL. I have often stumbled into trouble with reserved words. These days I escape everything, like `SHOW CREATE TABLE`, does because a) it easy and b) eliminates this whole class of defect.

On 2. I don't feel competent to judge. Consistency and convention have their merits. Otoh, I'm not keen on this particular convention.

On 3. Again, idk, since idk the typical use cases for `CDbCommandBuilder` and thus how to weight performance against reduced defect rate.

I could be way off base here but I had been under the impression that `CDbCommandBuilder` was intended for less senior users. I don't use it because I prefer CActiveRecord and am an experienced SQL author (except that I can't remember reserved words;). If my impression is right then `CDbCommandBuilder` should maybe put being helpful first.