Ryan What would happen if you defined a column so that you could use the normal pushdown mechanism? In most cases, you wouldn't return the value of the column since the only purpose is to use as a filter, but nothing should prevent you from returning the value of this not-really-a-column.
By letting it be considered as if a column, all of the normal mechanisms can be brought to bear. Another case can be seen in how the CSV reader lets your inject separators and such. On Sat, Apr 7, 2018, 16:23 Ryan Shanks <ryan.sha...@softcomcorp.com> wrote: > Hi Drill Dev Team! > > I am writing a custom storage plugin and I am curious if it is possible > in Drill to pass a filter value, in the form of a where clause, that is > not related to a column. What I would like to accomplish is something like: > > select * from myTable where notColumn = 'value'; > > In the example, notColumn is not a column in myTable, or any other > table, it is just a specific parameter that the storage plugin will use > in the filtering process. Additionally, notColumn would not be returned > as a column so Drill needs to not expect it as a part of the 'select *'. > I created a rule that will push down and remove these non-column filter > calls, but I need to somehow tell drill/calcite that the filter name is > valid, without actually registering it as a column. The following error > occurs prior to submitting any rules: > > org.apache.drill.common.exceptions.UserRemoteException: VALIDATION > ERROR: From line 1, column 35 to line 1, column 39: Column 'notColumn' > not found in any table > > > Alternatively, can I manipulate star queries to only return a subset of > all the columns for a table? > > Any insight would be greatly appreciated! > > Thanks, > Ryan >