In Drill we create table functions for valid table names in the DFSStoragePlugin. To make sure these won't collide with existing functions, I took a stab at adding a FuctionCategory for table functions. Otherwise the TableFunctions were considered in many contexts and causing problems. Here it is: https://github.com/apache/calcite/pull/168 Let me know what you think.
On Thu, Nov 19, 2015 at 1:35 PM, Julian Hyde <[email protected]> wrote: > Suppose you have a function that returns an array of records. You might > want to use it in the SELECT clause to produce an array-valued column and > you might want to use in the FROM clause to produce a table. > > I don’t know for sure it’s a necessary restriction, but why take the > chance? It’s hard to unify 2 namespaces, much easier to keep it as a single > namespace from the start. Users know that it’s daft to give a table and a > function the same name. > > > > On Nov 19, 2015, at 1:26 PM, Julien Le Dem <[email protected]> wrote: > > > > Is it a necessary restriction? > > It looks like they are called in 2 different contexts and that there's no > > ambiguity whether we want a table function or otherwise. > > > > On Thu, Nov 19, 2015 at 1:04 PM, Julian Hyde <[email protected]> wrote: > > > >> Table functions and regular functions occupy the same namespace. You > can’t > >> “overload” on what kind of function it is. > >> > >>> On Nov 19, 2015, at 1:01 PM, Julien Le Dem <[email protected]> wrote: > >>> > >>> Right now when calcite asks the schema for functions by name it does > not > >>> provide context whether we want a TableFunction or a regular function. > >>> This create problems when there are collisions between table functions > >> and > >>> regular functions. > >>> In my case in Drill anything that can be a valid table is a valid table > >>> function and that includes all functions. > >>> Would it be possible to change this so that the schema knows what type > of > >>> function we want? > >>> > >>> -- > >>> Julien > >> > >> > > > > > > -- > > Julien > > -- Julien
