Actually a quick follow up, mostly for anyone that finds this thread. It isn't necessary to re-build drill to work with UDFs, if they can be found anywhere on the classpath when Drill is running, they will be discovered and added to the function registry which ties into the SQL validation in optiq.
-Jason On Mon, Sep 22, 2014 at 9:42 AM, Jason Altekruse <[email protected]> wrote: > Hi Yash, > > I did not work on the code for this, but if the functions are just acting > on columns to provide aggregates I believe they are just supported by > Drills default mechanism for tying into the parser. We ended up modifying > the parser with some FreeMarker hooks that allows for consumers of optiq to > provide custom syntax that extends the parser without forking the whole > thing. > > I believe that this works together with our function registry to provide > default support for UDFs (which our system functions are defined in the > same way as UDFs) without having to modify the parser itself. I haven't had > any trouble just adding new DrillFuncs and having them be discovered by > Drill and work after a new build. I believe I have only written scalar > functions and not aggregations, but you can look at the SumFunctions class > for some reference on the differences. > > -Jason > > On Mon, Sep 22, 2014 at 7:50 AM, Yash Sharma <[email protected]> wrote: > >> Hi All, >> I am planning to add new drill functions to optiq syntax for parsing. >> We have new functions like regr_avgx/regr_avgy etc and existing ones like >> covar_samp,covar_pop, correlation/corr etc. >> >> Going through this old thread[1] I see that we need to add the definitions >> in the CombinedParser.jj[2] in Optiq. >> >> Is that the way we still use or its handled differently now ? >> >> Thanks. >> >> 1: https://groups.google.com/forum/#!topic/optiq-dev/dkkxsHh2MnE >> 2. >> >> https://github.com/yssharma/optiq/blob/retired/core/src/main/codegen/templates/CombinedParser.jj >> > >
