FWIW, there is also a similar FLIP[1] in Flink trying to do similar thing, which you might be interested in.
[1] https://cwiki.apache.org/confluence/display/FLINK/FLIP-348%3A+Make+expanding+behavior+of+virtual+metadata+columns+configurable Julian Hyde <[email protected]> 于2023年9月2日周六 06:42写道： > > I’d write a jira case, specifying the feature in such a way that everyone who > uses Calcite can benefit from it, then I’d write some unit tests (including > some negative tests), and then the coding part would be relatively > straightforward. > > Probably not the answer you were hoping for, but that’s honestly how I’d > approach it. > > Julian > > PS Please subscribe to dev@ so that you receive replies and so that your > reply does not need to be moderated. > > > On Sep 1, 2023, at 4:00 AM, Gonzalo Ortiz Jaureguizar > > <[email protected]> wrote: > > > > Hi there, > > > > I'm a contributor to Apache Pinot, which uses Apache Calcite under the > > hood. Like some other databases, Pinot defines some *private* columns that > > customers can use, but they are not included in select * by default. I > > guess this is a not so strange pattern. For example, Postgres does the same > > with `xmin` and `xmax`. > > > > My question is: What is the correct way to implement this behavior? We > > initially override SqlValidatorImpl.expandStar in our own Validator, but > > recently we have enabled identifierExpansion and these columns are > > projected again. > > > > Reading the code, it looks like we could > > override SqlValidatorImpl.addToSelectList doing something like: > > > > ``` > > protected void addToSelectList( > > List<SqlNode> list, > > Set<String> aliases, > > List<Map.Entry<String, RelDataType>> fieldList, > > SqlNode exp, > > SelectScope scope, > > final boolean includeSystemVars) { > > if (!isPrivateColumn(exp)) { > > super.addToSelectList(list, aliases, fieldList, expr, scope, > > includeSystemVars); > > } > > } > > ``` > > > > But the javadoc doesn't say that it is allowed to not add the column to > > list and fieldList, so that change may break something. > -- Best, Benchao Li
