>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