I managed to put together the validation and sequence resolving stuff, but had a little problem with making the RelOptTable a RexLiteral. The current patch looks a bit ugly since the changes get everywhere in order to make RexLiteral enclose this RelOptTable object. An alternative I'm thinking is to create a new RexNode type, say, RexTableReference (or RexSequenceReference). Any suggestions, Julian Hyde?

BTW, the existing test cases in sequence.oq pass with this patch, and I'll add counter cases later. Having a new RexNode type would require same amount of changes but would look nicer, IMO.

Maryann Xue, The functionality I mentioned in our call this morning was EnumerableRelImplementor.stash. It allows you to pass in an object at implement time (i.e. when you are converting a RelNode tree to java code) and to be able to get that object at execute time (i.e. after that java code has been compiled using janino and is being run). See CALCITE-506.

I don't know whether it solves the problem we have here, but I thought I'd mention it. The life cycle is slightly different. It's as if we need to stash an object (the sequence object) at parse/validate time and retrieve that object at implement or run time. But without putting the object into the RexNode tree. What we'd put into the RexNode tree is a RexDynamicParam with a unique name, and we'd have a map somewhere outside the RexNode tree from that name to the object value.

Maryann Xue, I created a branch https://github.com/julianhyde/calcite/tree/992-validate-seq with your change, then I made my own change, backing out some of your edits and adding my own. You'll see that I don't pass the sequence table object but instead pass its unique name (a list of strings, converted temporarily into a single string like "schema"."table". That string can be converted to a string list, then used to get a RelOptTable inside the code that implements the sequence function by generating java code. Hopefully that's what you need.

Thank you, Julian Hyde, for making the changes! Yes, the THREAD_LOCAL object does exactly what is needed, with the help of the "to string" and "from string" for qualified names. I have some minor questions, which I have posted on the pull request.

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/de38802. Thanks , Julian Hyde, for your help!

Resolved in release 1.6.0 (2016-01-22).