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
