You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julien Le Dem <ju...@dremio.com> on 2015/11/19 22:01:30 UTC
Schema.getFunctions(name)
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
Re: Schema.getFunctions(name)
Posted by Julian Hyde <jh...@apache.org>.
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 <ju...@dremio.com> 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 <jh...@apache.org> 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 <ju...@dremio.com> 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 <jh...@apache.org> 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 <ju...@dremio.com> 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
Re: Schema.getFunctions(name)
Posted by Julien Le Dem <ju...@dremio.com>.
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 <jh...@apache.org> 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 <ju...@dremio.com> 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 <jh...@apache.org> 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 <ju...@dremio.com> 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
Re: Schema.getFunctions(name)
Posted by Julian Hyde <jh...@apache.org>.
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 <ju...@dremio.com> 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 <jh...@apache.org> 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 <ju...@dremio.com> 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
Re: Schema.getFunctions(name)
Posted by Julien Le Dem <ju...@dremio.com>.
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 <jh...@apache.org> 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 <ju...@dremio.com> 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
Re: Schema.getFunctions(name)
Posted by Julian Hyde <jh...@apache.org>.
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 <ju...@dremio.com> 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