If JDBCAppender is removed thre would be a single exception thrown at config time
Once again: there are valid cases when people override `flushBuffer` and implement secure database calls. In other words, they find "buffering" feature useful. If we drop the class altogether, the users would have to rewrite/recompile the code which is harder than just replacing log4j.jar with reload4j.jar. if we keep the class, we could still keep the "drop-in replacement" label which would be very good. That is why I suggest we keep the class, and we heal SQL injection.
Then there is the case of MDC (%X), NCD (%x) and many other cases which we did not anticipate
We can hard-code things like "we support PatternLayout only", then we know the full set of markers (e.g. everything with %). Vladimir