At a high level, it sounds like a great idea. However, let’s drill into the details:
1. What code changes to you intend to make to the Calcite base? You could (a) define your own “<“ operator (using it instead of SqlStdOperatorTable.LESS_THAN), or (b) modify OperandTypes.COMPARABLE_ORDERED_COMPARABLE_ORDERED (the policy used by LESS_THAN), or (c) modify something in the type system. Each of those could work, but would change a different piece of code, and that would affect how the code is maintained. 2. How do you intend to test this? When ANY was introduced, I was surprised how little testing was done, given that ANY has a pervasive impact: it an occur in any scalar expression, and therefore you need to devise a way to test every operator. I don’t know whether there is an easy way to test this, but if we don’t devise an effective way to test it, we will face an endless trickle of patches for this and that case that we forgot to address. Before I support this I will need to see a cogent plan for avoiding (or at least managing) large-scale code changes, and a plan to comprehensively test the full set of operators and functions. Also, a question about requirements: Will all users in a Calcite instance (a JVM) be using the same type system? Or might it vary by, say, schema or connection? Julian > On Jan 15, 2016, at 10:17 AM, Hsuan Yi Chu <[email protected]> wrote: > > Hi all, > I am wondering if anybody would some other ideas regarding this proposal ? > > In fact, I think this is customization is really beneficial since different > systems have their own type rules. Allowing this customization to happen > can really help calcite work with other systems. > > On Mon, Jan 11, 2016 at 11:55 AM, Hsuan Yi Chu <[email protected]> wrote: > >> Hi all, >> Since Calcite has been used as planners for many projects, each with its >> own definition of flexibility, I am thinking if we could make >> type-check-mechanism plugable? >> >> For the first example, currently, the following filter will trigger >> exception: >> >> col - to_timestamp('XXXX-XX-XX XX:XX:XX','YYYY-MM-dd HH:mm:ss') < interval >> 'X XX:XX:X' day to second >> >> => Cannot apply '-' to arguments of type '<ANY> - <TIMESTAMP(0)> >> >> >> >> Another example is cast function, where less type conversion is allowed in >> calcite than in Drill or MS-SQL. >> >> Please let me know if this proposal makes sense. >>
