The current JdbcInterpreter implementation seems too generic for me.
Two main reasons
1. The logic of executing sql in JdbcInterpeter is a little weird. Here's
is what jdbc interpreter would do for "%jdbc(mysql) show tables"
The script part is actually `(mysql) show tables` rather than `show
tables`, jdbc interpreter first parse it to get property key `mysql` then
execute sql `show tables` for mysql. This is kind weird to do parsing in
jdbc interpreter. I would use '%jdbc(mysql)' as interpreter name part,
`mysql` could be some kind of interpreter property, but never to make
interpreter to do parsing again. 'show tables' should be the sql script
part which is sent to jdbc interpreter. Doing specific parsing in
interpreter is not a good practise IMHO. This also make the parsing
repl/script logic a little weird in Paragraph.java
2. All the database would share the same interpreter setting. such as
keytab, principal, common.max_count. And it just depends on the propertyKey
to decide to connect which database. I would say it is better to create one
interpreter setting for each database rather than mixing them together,
this would cause JdbcInterpreter very fragile, as changes for one database
may affect other databases. I am not sure whether this is because creating
new interpreter setting is not available when the jdbc interpreter is
implemented. if user create interpreter setting for each database, then he
doesn't need to specify `(mysql)` as point 1.
Welcome any comments and thoughts on this.
