Ted Xu, I'm interested about your use case of using a different operator table. Are you intending to add some additional operators over and above the standard ones? For this, ChainedSqlOperatorTable is useful. You would still have the SqlStdOperatorTable underneath, so it would be the same instance of, say, the EQUALS operator.
But if your use case is different, tell us what it is, let's figure out an official way to support it.
Your patch looks basically good. And by the way, I just fixed
CALCITE-1039, which provides SqlKind values for several more built-in operators. (It will be merged to master in the next day or two, but for now you can see it at https://github.com/julianhyde/calcite/commit/904c73da60b9f9deec61ea34d89ada3462381f93.)
Have you found and fixed all places where we compare operators by identity, or just the ones that were causing you trouble?
It would be really useful if your patch contained a test case. You could add a test to FrameworksTest that creates an operator table similar to the one in your project then calls
FrameworkConfig config = Frameworks.newConfigBuilder().operatorTable(myTable).build();
so that it gets used during parsing/validation/planning.
I'll accept the patch when it has a test case and when you're fairly sure you've replaced all the operator identity comparisons you need.