Description: ------------ Conceivably, the Parser may differ behavior-wise between different dialects. For example, if one dialect allows FROM clauses within UPDATE statements, another might not. A bridge design pattern would fit this problem space well, allowing a Parser abstract class, with {MySQL,MSSQL,ANSI,etc} derived classes, each calling functions from a Parser_Implementation. Then you have different implementation derived classes for each dialect. This pattern is flexible enough to handle any differences between dialects, including changes in policy. The current setup only handles differences in allowed symbols.

Wow, was I thinking about that wrong. You wouldn't have MySQL_Abstract_Parser <-> MySQL_Parser_Implementation split, because you would never want to do MySQL_Abstract_Parser <-> MSSQL_Parser_Implementation. A bridge makes no sense in this scenario. But something does need to happen to make this code closed against policy changes. Probably making the dialects full-fledged subclasses with template methods is the way to go.

I think we can safely stick with setting little behavior change flags in the dialect files for now. The differences in behavior are so minor.