Thanks - I’ve made some comments on the JIRA. Let’s continue conversation there.
> On Nov 24, 2015, at 3:58 PM, Julien Le Dem <[email protected]> wrote: > > 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
