You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@calcite.apache.org by Valli Annamalai <ai...@gmail.com> on 2018/04/20 11:27:46 UTC

How to create user-defined data types in calcite?

I want to parse a query having 'text' in place of 'varchar'. For
example, select
cast(ps_comment as text) from part While parsing calcite is showing,
Unknown data type name 'TEXT'.

How can I make calcite to parse the above query successfully having
user-defined data type 'text'?


Thanks in advance

Re: How to create user-defined data types in calcite?

Posted by Shuyi Chen <su...@gmail.com>.

What do you mean by work with JSON only? You can define your own type in 2
ways:
1) define it  using CREATE TYPE (see here
<https://github.com/apache/calcite/blob/master/site/_docs/reference.md#ddl-extensions>
)
2) define it with JSON schema (see here
<https://github.com/apache/calcite/blob/master/site/_docs/model.md#type>)

Thanks.

On Thu, Apr 26, 2018 at 3:58 AM, aishwaryaanns@gmail.com <
aishwaryaanns@gmail.com> wrote:

> But CREATE TYPE works only with JSON right? Is there any way other than
> that?
>
> On 2018/04/21 00:41:23, Shuyi Chen <su...@gmail.com> wrote:
> > Currently, user defined type is not supported in Calcite. But it's WIP,
> > please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
> > PR, you can either use CREATE TYPE statement to define your own type or
> > define your new type in the JSON schema.
> >
> > Thanks
> > Shuyi
> >
> >
> > On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> aishwaryaanns@gmail.com>
> > wrote:
> >
> > > I want to parse a query having 'text' in place of 'varchar'. For
> > > example, select
> > > cast(ps_comment as text) from part While parsing calcite is showing,
> > > Unknown data type name 'TEXT'.
> > >
> > > How can I make calcite to parse the above query successfully having
> > > user-defined data type 'text'?
> > >
> > >
> > > Thanks in advance
> > >
> >
> >
> >
> > --
> > "So you have to trust that the dots will somehow connect in your future."
> >
>



-- 
"So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by .

But CREATE TYPE works only with JSON right? Is there any way other than that?

On 2018/04/21 00:41:23, Shuyi Chen <su...@gmail.com> wrote: 
> Currently, user defined type is not supported in Calcite. But it's WIP,
> please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
> PR, you can either use CREATE TYPE statement to define your own type or
> define your new type in the JSON schema.
> 
> Thanks
> Shuyi
> 
> 
> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <ai...@gmail.com>
> wrote:
> 
> > I want to parse a query having 'text' in place of 'varchar'. For
> > example, select
> > cast(ps_comment as text) from part While parsing calcite is showing,
> > Unknown data type name 'TEXT'.
> >
> > How can I make calcite to parse the above query successfully having
> > user-defined data type 'text'?
> >
> >
> > Thanks in advance
> >
> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."
>

Re: How to create user-defined data types in calcite?

Posted by Michael Mior <mm...@uwaterloo.ca>.

Good point about the rebase. I would suggest that as the proposed process
since it means we don't lose changes mistakenly committed to site. I would
suggest that after the rebase, "git log master..site" to be run to ensure
that it produces no output. So the only purpose of the rebase vs "git reset
--hard origin/master" is tto catch commits that have snuck directly into
the `site` branch.

--
Michael Mior
mmior@uwaterloo.ca

2018-04-25 14:41 GMT-04:00 Julian Hyde <jh...@gmail.com>:

> I think if you rebase “site” onto “master”, git will spot commits that are
> already on “site”.
>
> $ git checkout site
> $ git rebase -i origin master
>
> All being well, site should end up identical to master after the rebase.
> So force-push is not scary.
>
> Julian
>
>
> > On Apr 25, 2018, at 11:31 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >
> > Sure, I understand. But no one can do a fast-forward merge to the site
> > branch unless they know for sure that nothing in there is going to make
> > changes to the site that shouldn't be deployed. And then we're back to
> > whoever updates the site needing to already know what should be deployed.
> >
> > I'm suggesting the following:
> >
> > 1. During development, cherry pick *only* commits which affect the site
> > from `master` to `site`
> > 2. At release time, force push the `master` branch to `site`.
> > Unfortunately, this means if someone does mistakenly make site changes
> > directly to the `site` branch, then these will be lost. I don't see an
> easy
> > way of preventing this.
> >
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> >
> > 2018-04-25 14:25 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >
> >> Well, consider the current “master” and “site” branches[1]. They were in
> >> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3],
> which
> >> had changes to the site related to product features, so “master” and
> “site”
> >> had to diverge.
> >>
> >> It isn’t always possible for “master” and “site” to be on the same path,
> >> but for this release, it was until just before CALCITE-2045.
> >>
> >> Julian
> >>
> >> [1] https://github.com/apache/calcite/network <
> https://github.com/apache/
> >> calcite/network>
> >>
> >> [2] https://github.com/apache/calcite/commit/
> >> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/
> >> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a>
> >>
> >> [3] https://github.com/apache/calcite/commit/
> >> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/
> >> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c>
> >>
> >>
> >>
> >>> On Apr 25, 2018, at 11:16 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >>>
> >>> I don't see how the sync with the master branch could be a fast-forward
> >>> merge. This isn't possible if commits just affecting the site have been
> >>> cherry picked since the last sync.
> >>>
> >>> --
> >>> Michael Mior
> >>> mmior@uwaterloo.ca
> >>>
> >>> 2018-04-25 14:13 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>
> >>>> My personal opinion about (non-fast-forward) merge commits: never do
> >> them.
> >>>>
> >>>> If site and master can be on the same line (i.e. if there is no new
> >>>> product-related changes to the site) then they should be.
> >>>>
> >>>> If they need to diverge, then cherry-pick individual commits from
> master
> >>>> to site.
> >>>>
> >>>> I added some instructions at the end of https://github.com/apache/
> >>>> calcite/blob/master/site/README.md <https://github.com/apache/
> >>>> calcite/blob/master/site/README.md>.
> >>>>
> >>>> Julian
> >>>>
> >>>>
> >>>>
> >>>>> On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca>
> wrote:
> >>>>>
> >>>>> Sure. Although there (at least) two ways of syncing site with master.
> >> One
> >>>>> being to force push master to the site branch and the other to merge
> >> the
> >>>>> master branch into site. I do kind of like the idea of the force push
> >>>> just
> >>>>> to avoid having the site branch be eternally filled with a bunch of
> >> merge
> >>>>> commits.
> >>>>>
> >>>>> One thing that didn't immediately occur to me is what happens with
> the
> >>>>> Javadoc?
> >>>>>
> >>>>> --
> >>>>> Michael Mior
> >>>>> mmior@uwaterloo.ca
> >>>>>
> >>>>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>>>
> >>>>>> A force-push to the “site” branch each release would not be a
> terrible
> >>>>>> thing. (Force-pushes are only suspect when they are to the master
> >>>> branch or
> >>>>>> a release branch.) Before the release, the release manager should
> make
> >>>> sure
> >>>>>> that edits on “site" have made it to “master”. Right after the
> >> release,
> >>>>>> they will deploy the site from the “site” branch, which almost
> >> certainly
> >>>>>> means syncing “site" with “master”.
> >>>>>>
> >>>>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca>
> >> wrote:
> >>>>>>>
> >>>>>>> Sounds reasonable to me. I like that better than the current
> approach
> >>>> of
> >>>>>>> whoever is updating the site needing to maintain mental state on
> what
> >>>> is
> >>>>>>> and isn't ready to be posted. We should of course add documentation
> >> for
> >>>>>>> this as part of the release process. We also should make clear in
> the
> >>>>>> site
> >>>>>>> documentation that nothing should be committed to the site branch
> >>>>>> directly,
> >>>>>>> but only what is cherry picked from master. I might even suggest
> that
> >>>> the
> >>>>>>> sync which happens during release be a force push of the current
> >> master
> >>>>>> to
> >>>>>>> the site branch, but I'm not sure I like that idea.
> >>>>>>>
> >>>>>>> --
> >>>>>>> Michael Mior
> >>>>>>> mmior@uwaterloo.ca
> >>>>>>>
> >>>>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>>>>>
> >>>>>>>> I am adding Kevin to the committers list, and I am seeing the
> >> problem
> >>>> of
> >>>>>>>> mixed changes - recently Michael has edited the site to add two
> PMC
> >>>>>>>> members, and Shuyi has added documentation for CREATE TYPE. We
> want
> >>>> the
> >>>>>>>> former to appear on the site, but the latter should wait until the
> >>>>>> release.
> >>>>>>>>
> >>>>>>>> I propose to create a “site” git branch that cherry-picks changes
> >> that
> >>>>>> we
> >>>>>>>> wish to have appear on the site immediately.
> >>>>>>>>
> >>>>>>>> On each release, it would be in sync with master, but might start
> to
> >>>>>>>> differ when we add documentation for features. It would sync up on
> >> the
> >>>>>> next
> >>>>>>>> release.
> >>>>>>>>
> >>>>>>>> Any comments/objections?
> >>>>>>>>
> >>>>>>>> Julian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>> You are right. Thanks a lot for the explanation, Julian.
> >>>>>>>>>
> >>>>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I think it’s misleading to end-users if the web site contains
> >>>> features
> >>>>>>>>>> that have not yet been released. So, we aim to re-generate the
> web
> >>>>>> site
> >>>>>>>>>> just after a release. (For non product-related stuff, such as
> >>>>>> committers
> >>>>>>>>>> and upcoming talks, we change the web site continuously. The
> >> person
> >>>>>>>>>> maintaining the web site has to be a bit careful not to publish
> >> the
> >>>>>>>> wrong
> >>>>>>>>>> stuff.)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> @Julian, thanks for reviewing the code. I think we need to
> >>>> regenerate
> >>>>>>>> the
> >>>>>>>>>>> website as well so that it contains the latest documentation on
> >>>> type
> >>>>>>>>>>> collection and type DDLs. Let me know how I can help.
> >>>>>>>>>>>
> >>>>>>>>>>> @Valli, with the latest master, you should be able to either
> use
> >>>>>> CREATE
> >>>>>>>>>>> TYPE statement to define your own type or define your new type
> in
> >>>> the
> >>>>>>>>>> JSON
> >>>>>>>>>>> schema.
> >>>>>>>>>>>
> >>>>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <
> suez1224@gmail.com
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
> >>>>>> anything.
> >>>>>>>>>>>>
> >>>>>>>>>>>> shuyi
> >>>>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jhyde@apache.org
> >
> >>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
> >>>> Shuyi)
> >>>>>>>> but
> >>>>>>>>>> I
> >>>>>>>>>>>>> reviewed it yesterday and am currently testing, so it should
> be
> >>>>>>>>>> committed
> >>>>>>>>>>>>> to master shortly.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <suez1224@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Currently, user defined type is not supported in Calcite.
> But
> >>>> it's
> >>>>>>>>>> WIP,
> >>>>>>>>>>>>>> please see https://issues.apache.org/
> jira/browse/CALCITE-2045
> >> .
> >>>>>> With
> >>>>>>>>>>>>> this
> >>>>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your
> >> own
> >>>>>> type
> >>>>>>>>>> or
> >>>>>>>>>>>>>> define your new type in the JSON schema.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>> Shuyi
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>>>>>>>>>> aishwaryaanns@gmail.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I want to parse a query having 'text' in place of
> 'varchar'.
> >>>> For
> >>>>>>>>>>>>>>> example, select
> >>>>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
> >>>>>>>> showing,
> >>>>>>>>>>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> How can I make calcite to parse the above query
> successfully
> >>>>>> having
> >>>>>>>>>>>>>>> user-defined data type 'text'?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks in advance
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> "So you have to trust that the dots will somehow connect in
> >> your
> >>>>>>>>>>>>> future."
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>> "So you have to trust that the dots will somehow connect in
> your
> >>>>>>>>>> future."
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> "So you have to trust that the dots will somehow connect in
> your
> >>>>>>>> future."
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>> future."
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@gmail.com>.

I think if you rebase “site” onto “master”, git will spot commits that are already on “site”.

$ git checkout site
$ git rebase -i origin master

All being well, site should end up identical to master after the rebase. So force-push is not scary.

Julian


> On Apr 25, 2018, at 11:31 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> 
> Sure, I understand. But no one can do a fast-forward merge to the site
> branch unless they know for sure that nothing in there is going to make
> changes to the site that shouldn't be deployed. And then we're back to
> whoever updates the site needing to already know what should be deployed.
> 
> I'm suggesting the following:
> 
> 1. During development, cherry pick *only* commits which affect the site
> from `master` to `site`
> 2. At release time, force push the `master` branch to `site`.
> Unfortunately, this means if someone does mistakenly make site changes
> directly to the `site` branch, then these will be lost. I don't see an easy
> way of preventing this.
> 
> --
> Michael Mior
> mmior@uwaterloo.ca
> 
> 2018-04-25 14:25 GMT-04:00 Julian Hyde <jh...@apache.org>:
> 
>> Well, consider the current “master” and “site” branches[1]. They were in
>> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], which
>> had changes to the site related to product features, so “master” and “site”
>> had to diverge.
>> 
>> It isn’t always possible for “master” and “site” to be on the same path,
>> but for this release, it was until just before CALCITE-2045.
>> 
>> Julian
>> 
>> [1] https://github.com/apache/calcite/network <https://github.com/apache/
>> calcite/network>
>> 
>> [2] https://github.com/apache/calcite/commit/
>> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/
>> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a>
>> 
>> [3] https://github.com/apache/calcite/commit/
>> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/
>> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c>
>> 
>> 
>> 
>>> On Apr 25, 2018, at 11:16 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>>> 
>>> I don't see how the sync with the master branch could be a fast-forward
>>> merge. This isn't possible if commits just affecting the site have been
>>> cherry picked since the last sync.
>>> 
>>> --
>>> Michael Mior
>>> mmior@uwaterloo.ca
>>> 
>>> 2018-04-25 14:13 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>> 
>>>> My personal opinion about (non-fast-forward) merge commits: never do
>> them.
>>>> 
>>>> If site and master can be on the same line (i.e. if there is no new
>>>> product-related changes to the site) then they should be.
>>>> 
>>>> If they need to diverge, then cherry-pick individual commits from master
>>>> to site.
>>>> 
>>>> I added some instructions at the end of https://github.com/apache/
>>>> calcite/blob/master/site/README.md <https://github.com/apache/
>>>> calcite/blob/master/site/README.md>.
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>> 
>>>>> On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>>>>> 
>>>>> Sure. Although there (at least) two ways of syncing site with master.
>> One
>>>>> being to force push master to the site branch and the other to merge
>> the
>>>>> master branch into site. I do kind of like the idea of the force push
>>>> just
>>>>> to avoid having the site branch be eternally filled with a bunch of
>> merge
>>>>> commits.
>>>>> 
>>>>> One thing that didn't immediately occur to me is what happens with the
>>>>> Javadoc?
>>>>> 
>>>>> --
>>>>> Michael Mior
>>>>> mmior@uwaterloo.ca
>>>>> 
>>>>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>>>> 
>>>>>> A force-push to the “site” branch each release would not be a terrible
>>>>>> thing. (Force-pushes are only suspect when they are to the master
>>>> branch or
>>>>>> a release branch.) Before the release, the release manager should make
>>>> sure
>>>>>> that edits on “site" have made it to “master”. Right after the
>> release,
>>>>>> they will deploy the site from the “site” branch, which almost
>> certainly
>>>>>> means syncing “site" with “master”.
>>>>>> 
>>>>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca>
>> wrote:
>>>>>>> 
>>>>>>> Sounds reasonable to me. I like that better than the current approach
>>>> of
>>>>>>> whoever is updating the site needing to maintain mental state on what
>>>> is
>>>>>>> and isn't ready to be posted. We should of course add documentation
>> for
>>>>>>> this as part of the release process. We also should make clear in the
>>>>>> site
>>>>>>> documentation that nothing should be committed to the site branch
>>>>>> directly,
>>>>>>> but only what is cherry picked from master. I might even suggest that
>>>> the
>>>>>>> sync which happens during release be a force push of the current
>> master
>>>>>> to
>>>>>>> the site branch, but I'm not sure I like that idea.
>>>>>>> 
>>>>>>> --
>>>>>>> Michael Mior
>>>>>>> mmior@uwaterloo.ca
>>>>>>> 
>>>>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>>>>>> 
>>>>>>>> I am adding Kevin to the committers list, and I am seeing the
>> problem
>>>> of
>>>>>>>> mixed changes - recently Michael has edited the site to add two PMC
>>>>>>>> members, and Shuyi has added documentation for CREATE TYPE. We want
>>>> the
>>>>>>>> former to appear on the site, but the latter should wait until the
>>>>>> release.
>>>>>>>> 
>>>>>>>> I propose to create a “site” git branch that cherry-picks changes
>> that
>>>>>> we
>>>>>>>> wish to have appear on the site immediately.
>>>>>>>> 
>>>>>>>> On each release, it would be in sync with master, but might start to
>>>>>>>> differ when we add documentation for features. It would sync up on
>> the
>>>>>> next
>>>>>>>> release.
>>>>>>>> 
>>>>>>>> Any comments/objections?
>>>>>>>> 
>>>>>>>> Julian
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com>
>> wrote:
>>>>>>>>> 
>>>>>>>>> You are right. Thanks a lot for the explanation, Julian.
>>>>>>>>> 
>>>>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I think it’s misleading to end-users if the web site contains
>>>> features
>>>>>>>>>> that have not yet been released. So, we aim to re-generate the web
>>>>>> site
>>>>>>>>>> just after a release. (For non product-related stuff, such as
>>>>>> committers
>>>>>>>>>> and upcoming talks, we change the web site continuously. The
>> person
>>>>>>>>>> maintaining the web site has to be a bit careful not to publish
>> the
>>>>>>>> wrong
>>>>>>>>>> stuff.)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com>
>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> @Julian, thanks for reviewing the code. I think we need to
>>>> regenerate
>>>>>>>> the
>>>>>>>>>>> website as well so that it contains the latest documentation on
>>>> type
>>>>>>>>>>> collection and type DDLs. Let me know how I can help.
>>>>>>>>>>> 
>>>>>>>>>>> @Valli, with the latest master, you should be able to either use
>>>>>> CREATE
>>>>>>>>>>> TYPE statement to define your own type or define your new type in
>>>> the
>>>>>>>>>> JSON
>>>>>>>>>>> schema.
>>>>>>>>>>> 
>>>>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <suez1224@gmail.com
>>> 
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
>>>>>> anything.
>>>>>>>>>>>> 
>>>>>>>>>>>> shuyi
>>>>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
>>>> Shuyi)
>>>>>>>> but
>>>>>>>>>> I
>>>>>>>>>>>>> reviewed it yesterday and am currently testing, so it should be
>>>>>>>>>> committed
>>>>>>>>>>>>> to master shortly.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Currently, user defined type is not supported in Calcite. But
>>>> it's
>>>>>>>>>> WIP,
>>>>>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045
>> .
>>>>>> With
>>>>>>>>>>>>> this
>>>>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your
>> own
>>>>>> type
>>>>>>>>>> or
>>>>>>>>>>>>>> define your new type in the JSON schema.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Shuyi
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>>>>>>>>>>>> aishwaryaanns@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'.
>>>> For
>>>>>>>>>>>>>>> example, select
>>>>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
>>>>>>>> showing,
>>>>>>>>>>>>>>> Unknown data type name 'TEXT'.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> How can I make calcite to parse the above query successfully
>>>>>> having
>>>>>>>>>>>>>>> user-defined data type 'text'?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks in advance
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> "So you have to trust that the dots will somehow connect in
>> your
>>>>>>>>>>>>> future."
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>>>>> future."
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>>> future."
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>> future."
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>>

Re: How to create user-defined data types in calcite?

Posted by Michael Mior <mm...@uwaterloo.ca>.

Sure, I understand. But no one can do a fast-forward merge to the site
branch unless they know for sure that nothing in there is going to make
changes to the site that shouldn't be deployed. And then we're back to
whoever updates the site needing to already know what should be deployed.

I'm suggesting the following:

1. During development, cherry pick *only* commits which affect the site
from `master` to `site`
2. At release time, force push the `master` branch to `site`.
Unfortunately, this means if someone does mistakenly make site changes
directly to the `site` branch, then these will be lost. I don't see an easy
way of preventing this.

--
Michael Mior
mmior@uwaterloo.ca

2018-04-25 14:25 GMT-04:00 Julian Hyde <jh...@apache.org>:

> Well, consider the current “master” and “site” branches[1]. They were in
> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], which
> had changes to the site related to product features, so “master” and “site”
> had to diverge.
>
> It isn’t always possible for “master” and “site” to be on the same path,
> but for this release, it was until just before CALCITE-2045.
>
> Julian
>
> [1] https://github.com/apache/calcite/network <https://github.com/apache/
> calcite/network>
>
> [2] https://github.com/apache/calcite/commit/
> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/
> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a>
>
> [3] https://github.com/apache/calcite/commit/
> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/
> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c>
>
>
>
> > On Apr 25, 2018, at 11:16 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >
> > I don't see how the sync with the master branch could be a fast-forward
> > merge. This isn't possible if commits just affecting the site have been
> > cherry picked since the last sync.
> >
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> >
> > 2018-04-25 14:13 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >
> >> My personal opinion about (non-fast-forward) merge commits: never do
> them.
> >>
> >> If site and master can be on the same line (i.e. if there is no new
> >> product-related changes to the site) then they should be.
> >>
> >> If they need to diverge, then cherry-pick individual commits from master
> >> to site.
> >>
> >> I added some instructions at the end of https://github.com/apache/
> >> calcite/blob/master/site/README.md <https://github.com/apache/
> >> calcite/blob/master/site/README.md>.
> >>
> >> Julian
> >>
> >>
> >>
> >>> On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >>>
> >>> Sure. Although there (at least) two ways of syncing site with master.
> One
> >>> being to force push master to the site branch and the other to merge
> the
> >>> master branch into site. I do kind of like the idea of the force push
> >> just
> >>> to avoid having the site branch be eternally filled with a bunch of
> merge
> >>> commits.
> >>>
> >>> One thing that didn't immediately occur to me is what happens with the
> >>> Javadoc?
> >>>
> >>> --
> >>> Michael Mior
> >>> mmior@uwaterloo.ca
> >>>
> >>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>
> >>>> A force-push to the “site” branch each release would not be a terrible
> >>>> thing. (Force-pushes are only suspect when they are to the master
> >> branch or
> >>>> a release branch.) Before the release, the release manager should make
> >> sure
> >>>> that edits on “site" have made it to “master”. Right after the
> release,
> >>>> they will deploy the site from the “site” branch, which almost
> certainly
> >>>> means syncing “site" with “master”.
> >>>>
> >>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca>
> wrote:
> >>>>>
> >>>>> Sounds reasonable to me. I like that better than the current approach
> >> of
> >>>>> whoever is updating the site needing to maintain mental state on what
> >> is
> >>>>> and isn't ready to be posted. We should of course add documentation
> for
> >>>>> this as part of the release process. We also should make clear in the
> >>>> site
> >>>>> documentation that nothing should be committed to the site branch
> >>>> directly,
> >>>>> but only what is cherry picked from master. I might even suggest that
> >> the
> >>>>> sync which happens during release be a force push of the current
> master
> >>>> to
> >>>>> the site branch, but I'm not sure I like that idea.
> >>>>>
> >>>>> --
> >>>>> Michael Mior
> >>>>> mmior@uwaterloo.ca
> >>>>>
> >>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>>>
> >>>>>> I am adding Kevin to the committers list, and I am seeing the
> problem
> >> of
> >>>>>> mixed changes - recently Michael has edited the site to add two PMC
> >>>>>> members, and Shuyi has added documentation for CREATE TYPE. We want
> >> the
> >>>>>> former to appear on the site, but the latter should wait until the
> >>>> release.
> >>>>>>
> >>>>>> I propose to create a “site” git branch that cherry-picks changes
> that
> >>>> we
> >>>>>> wish to have appear on the site immediately.
> >>>>>>
> >>>>>> On each release, it would be in sync with master, but might start to
> >>>>>> differ when we add documentation for features. It would sync up on
> the
> >>>> next
> >>>>>> release.
> >>>>>>
> >>>>>> Any comments/objections?
> >>>>>>
> >>>>>> Julian
> >>>>>>
> >>>>>>
> >>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> You are right. Thanks a lot for the explanation, Julian.
> >>>>>>>
> >>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> I think it’s misleading to end-users if the web site contains
> >> features
> >>>>>>>> that have not yet been released. So, we aim to re-generate the web
> >>>> site
> >>>>>>>> just after a release. (For non product-related stuff, such as
> >>>> committers
> >>>>>>>> and upcoming talks, we change the web site continuously. The
> person
> >>>>>>>> maintaining the web site has to be a bit careful not to publish
> the
> >>>>>> wrong
> >>>>>>>> stuff.)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>> @Julian, thanks for reviewing the code. I think we need to
> >> regenerate
> >>>>>> the
> >>>>>>>>> website as well so that it contains the latest documentation on
> >> type
> >>>>>>>>> collection and type DDLs. Let me know how I can help.
> >>>>>>>>>
> >>>>>>>>> @Valli, with the latest master, you should be able to either use
> >>>> CREATE
> >>>>>>>>> TYPE statement to define your own type or define your new type in
> >> the
> >>>>>>>> JSON
> >>>>>>>>> schema.
> >>>>>>>>>
> >>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <suez1224@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
> >>>> anything.
> >>>>>>>>>>
> >>>>>>>>>> shuyi
> >>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
> >>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
> >> Shuyi)
> >>>>>> but
> >>>>>>>> I
> >>>>>>>>>>> reviewed it yesterday and am currently testing, so it should be
> >>>>>>>> committed
> >>>>>>>>>>> to master shortly.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Currently, user defined type is not supported in Calcite. But
> >> it's
> >>>>>>>> WIP,
> >>>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045
> .
> >>>> With
> >>>>>>>>>>> this
> >>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your
> own
> >>>> type
> >>>>>>>> or
> >>>>>>>>>>>> define your new type in the JSON schema.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks
> >>>>>>>>>>>> Shuyi
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>>>>>>>> aishwaryaanns@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'.
> >> For
> >>>>>>>>>>>>> example, select
> >>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
> >>>>>> showing,
> >>>>>>>>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> How can I make calcite to parse the above query successfully
> >>>> having
> >>>>>>>>>>>>> user-defined data type 'text'?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks in advance
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> "So you have to trust that the dots will somehow connect in
> your
> >>>>>>>>>>> future."
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>>>> future."
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>> future."
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>> future."
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

Well, consider the current “master” and “site” branches[1]. They were in sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], which had changes to the site related to product features, so “master” and “site” had to diverge.

It isn’t always possible for “master” and “site” to be on the same path, but for this release, it was until just before CALCITE-2045.

Julian

[1] https://github.com/apache/calcite/network <https://github.com/apache/calcite/network>

[2] https://github.com/apache/calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a>

[3] https://github.com/apache/calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c>



> On Apr 25, 2018, at 11:16 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> 
> I don't see how the sync with the master branch could be a fast-forward
> merge. This isn't possible if commits just affecting the site have been
> cherry picked since the last sync.
> 
> --
> Michael Mior
> mmior@uwaterloo.ca
> 
> 2018-04-25 14:13 GMT-04:00 Julian Hyde <jh...@apache.org>:
> 
>> My personal opinion about (non-fast-forward) merge commits: never do them.
>> 
>> If site and master can be on the same line (i.e. if there is no new
>> product-related changes to the site) then they should be.
>> 
>> If they need to diverge, then cherry-pick individual commits from master
>> to site.
>> 
>> I added some instructions at the end of https://github.com/apache/
>> calcite/blob/master/site/README.md <https://github.com/apache/
>> calcite/blob/master/site/README.md>.
>> 
>> Julian
>> 
>> 
>> 
>>> On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>>> 
>>> Sure. Although there (at least) two ways of syncing site with master. One
>>> being to force push master to the site branch and the other to merge the
>>> master branch into site. I do kind of like the idea of the force push
>> just
>>> to avoid having the site branch be eternally filled with a bunch of merge
>>> commits.
>>> 
>>> One thing that didn't immediately occur to me is what happens with the
>>> Javadoc?
>>> 
>>> --
>>> Michael Mior
>>> mmior@uwaterloo.ca
>>> 
>>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>> 
>>>> A force-push to the “site” branch each release would not be a terrible
>>>> thing. (Force-pushes are only suspect when they are to the master
>> branch or
>>>> a release branch.) Before the release, the release manager should make
>> sure
>>>> that edits on “site" have made it to “master”. Right after the release,
>>>> they will deploy the site from the “site” branch, which almost certainly
>>>> means syncing “site" with “master”.
>>>> 
>>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>>>>> 
>>>>> Sounds reasonable to me. I like that better than the current approach
>> of
>>>>> whoever is updating the site needing to maintain mental state on what
>> is
>>>>> and isn't ready to be posted. We should of course add documentation for
>>>>> this as part of the release process. We also should make clear in the
>>>> site
>>>>> documentation that nothing should be committed to the site branch
>>>> directly,
>>>>> but only what is cherry picked from master. I might even suggest that
>> the
>>>>> sync which happens during release be a force push of the current master
>>>> to
>>>>> the site branch, but I'm not sure I like that idea.
>>>>> 
>>>>> --
>>>>> Michael Mior
>>>>> mmior@uwaterloo.ca
>>>>> 
>>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>>>> 
>>>>>> I am adding Kevin to the committers list, and I am seeing the problem
>> of
>>>>>> mixed changes - recently Michael has edited the site to add two PMC
>>>>>> members, and Shuyi has added documentation for CREATE TYPE. We want
>> the
>>>>>> former to appear on the site, but the latter should wait until the
>>>> release.
>>>>>> 
>>>>>> I propose to create a “site” git branch that cherry-picks changes that
>>>> we
>>>>>> wish to have appear on the site immediately.
>>>>>> 
>>>>>> On each release, it would be in sync with master, but might start to
>>>>>> differ when we add documentation for features. It would sync up on the
>>>> next
>>>>>> release.
>>>>>> 
>>>>>> Any comments/objections?
>>>>>> 
>>>>>> Julian
>>>>>> 
>>>>>> 
>>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>>>> 
>>>>>>> You are right. Thanks a lot for the explanation, Julian.
>>>>>>> 
>>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
>>>> wrote:
>>>>>>> 
>>>>>>>> I think it’s misleading to end-users if the web site contains
>> features
>>>>>>>> that have not yet been released. So, we aim to re-generate the web
>>>> site
>>>>>>>> just after a release. (For non product-related stuff, such as
>>>> committers
>>>>>>>> and upcoming talks, we change the web site continuously. The person
>>>>>>>> maintaining the web site has to be a bit careful not to publish the
>>>>>> wrong
>>>>>>>> stuff.)
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com>
>> wrote:
>>>>>>>>> 
>>>>>>>>> @Julian, thanks for reviewing the code. I think we need to
>> regenerate
>>>>>> the
>>>>>>>>> website as well so that it contains the latest documentation on
>> type
>>>>>>>>> collection and type DDLs. Let me know how I can help.
>>>>>>>>> 
>>>>>>>>> @Valli, with the latest master, you should be able to either use
>>>> CREATE
>>>>>>>>> TYPE statement to define your own type or define your new type in
>> the
>>>>>>>> JSON
>>>>>>>>> schema.
>>>>>>>>> 
>>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
>>>> anything.
>>>>>>>>>> 
>>>>>>>>>> shuyi
>>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
>> Shuyi)
>>>>>> but
>>>>>>>> I
>>>>>>>>>>> reviewed it yesterday and am currently testing, so it should be
>>>>>>>> committed
>>>>>>>>>>> to master shortly.
>>>>>>>>>>> 
>>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Currently, user defined type is not supported in Calcite. But
>> it's
>>>>>>>> WIP,
>>>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045.
>>>> With
>>>>>>>>>>> this
>>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your own
>>>> type
>>>>>>>> or
>>>>>>>>>>>> define your new type in the JSON schema.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Shuyi
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>>>>>>>>>> aishwaryaanns@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'.
>> For
>>>>>>>>>>>>> example, select
>>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
>>>>>> showing,
>>>>>>>>>>>>> Unknown data type name 'TEXT'.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> How can I make calcite to parse the above query successfully
>>>> having
>>>>>>>>>>>>> user-defined data type 'text'?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks in advance
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>>>>>> future."
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>>> future."
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>> future."
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>> future."
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>>

Re: How to create user-defined data types in calcite?

Posted by Michael Mior <mm...@uwaterloo.ca>.

I don't see how the sync with the master branch could be a fast-forward
merge. This isn't possible if commits just affecting the site have been
cherry picked since the last sync.

--
Michael Mior
mmior@uwaterloo.ca

2018-04-25 14:13 GMT-04:00 Julian Hyde <jh...@apache.org>:

> My personal opinion about (non-fast-forward) merge commits: never do them.
>
> If site and master can be on the same line (i.e. if there is no new
> product-related changes to the site) then they should be.
>
> If they need to diverge, then cherry-pick individual commits from master
> to site.
>
> I added some instructions at the end of https://github.com/apache/
> calcite/blob/master/site/README.md <https://github.com/apache/
> calcite/blob/master/site/README.md>.
>
> Julian
>
>
>
> > On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >
> > Sure. Although there (at least) two ways of syncing site with master. One
> > being to force push master to the site branch and the other to merge the
> > master branch into site. I do kind of like the idea of the force push
> just
> > to avoid having the site branch be eternally filled with a bunch of merge
> > commits.
> >
> > One thing that didn't immediately occur to me is what happens with the
> > Javadoc?
> >
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> >
> > 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >
> >> A force-push to the “site” branch each release would not be a terrible
> >> thing. (Force-pushes are only suspect when they are to the master
> branch or
> >> a release branch.) Before the release, the release manager should make
> sure
> >> that edits on “site" have made it to “master”. Right after the release,
> >> they will deploy the site from the “site” branch, which almost certainly
> >> means syncing “site" with “master”.
> >>
> >>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >>>
> >>> Sounds reasonable to me. I like that better than the current approach
> of
> >>> whoever is updating the site needing to maintain mental state on what
> is
> >>> and isn't ready to be posted. We should of course add documentation for
> >>> this as part of the release process. We also should make clear in the
> >> site
> >>> documentation that nothing should be committed to the site branch
> >> directly,
> >>> but only what is cherry picked from master. I might even suggest that
> the
> >>> sync which happens during release be a force push of the current master
> >> to
> >>> the site branch, but I'm not sure I like that idea.
> >>>
> >>> --
> >>> Michael Mior
> >>> mmior@uwaterloo.ca
> >>>
> >>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >>>
> >>>> I am adding Kevin to the committers list, and I am seeing the problem
> of
> >>>> mixed changes - recently Michael has edited the site to add two PMC
> >>>> members, and Shuyi has added documentation for CREATE TYPE. We want
> the
> >>>> former to appear on the site, but the latter should wait until the
> >> release.
> >>>>
> >>>> I propose to create a “site” git branch that cherry-picks changes that
> >> we
> >>>> wish to have appear on the site immediately.
> >>>>
> >>>> On each release, it would be in sync with master, but might start to
> >>>> differ when we add documentation for features. It would sync up on the
> >> next
> >>>> release.
> >>>>
> >>>> Any comments/objections?
> >>>>
> >>>> Julian
> >>>>
> >>>>
> >>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>>>
> >>>>> You are right. Thanks a lot for the explanation, Julian.
> >>>>>
> >>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
> >> wrote:
> >>>>>
> >>>>>> I think it’s misleading to end-users if the web site contains
> features
> >>>>>> that have not yet been released. So, we aim to re-generate the web
> >> site
> >>>>>> just after a release. (For non product-related stuff, such as
> >> committers
> >>>>>> and upcoming talks, we change the web site continuously. The person
> >>>>>> maintaining the web site has to be a bit careful not to publish the
> >>>> wrong
> >>>>>> stuff.)
> >>>>>>
> >>>>>>
> >>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> @Julian, thanks for reviewing the code. I think we need to
> regenerate
> >>>> the
> >>>>>>> website as well so that it contains the latest documentation on
> type
> >>>>>>> collection and type DDLs. Let me know how I can help.
> >>>>>>>
> >>>>>>> @Valli, with the latest master, you should be able to either use
> >> CREATE
> >>>>>>> TYPE statement to define your own type or define your new type in
> the
> >>>>>> JSON
> >>>>>>> schema.
> >>>>>>>
> >>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
> >> anything.
> >>>>>>>>
> >>>>>>>> shuyi
> >>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
> >> wrote:
> >>>>>>>>
> >>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
> Shuyi)
> >>>> but
> >>>>>> I
> >>>>>>>>> reviewed it yesterday and am currently testing, so it should be
> >>>>>> committed
> >>>>>>>>> to master shortly.
> >>>>>>>>>
> >>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
> >> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Currently, user defined type is not supported in Calcite. But
> it's
> >>>>>> WIP,
> >>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045.
> >> With
> >>>>>>>>> this
> >>>>>>>>>> PR, you can either use CREATE TYPE statement to define your own
> >> type
> >>>>>> or
> >>>>>>>>>> define your new type in the JSON schema.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Shuyi
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>>>>>> aishwaryaanns@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'.
> For
> >>>>>>>>>>> example, select
> >>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
> >>>> showing,
> >>>>>>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>>>>>
> >>>>>>>>>>> How can I make calcite to parse the above query successfully
> >> having
> >>>>>>>>>>> user-defined data type 'text'?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks in advance
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>>>>> future."
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>> future."
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>> future."
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> "So you have to trust that the dots will somehow connect in your
> >> future."
> >>>>
> >>>>
> >>
> >>
>
>

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

My personal opinion about (non-fast-forward) merge commits: never do them.

If site and master can be on the same line (i.e. if there is no new product-related changes to the site) then they should be.

If they need to diverge, then cherry-pick individual commits from master to site.

I added some instructions at the end of https://github.com/apache/calcite/blob/master/site/README.md <https://github.com/apache/calcite/blob/master/site/README.md>.

Julian



> On Apr 25, 2018, at 11:06 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> 
> Sure. Although there (at least) two ways of syncing site with master. One
> being to force push master to the site branch and the other to merge the
> master branch into site. I do kind of like the idea of the force push just
> to avoid having the site branch be eternally filled with a bunch of merge
> commits.
> 
> One thing that didn't immediately occur to me is what happens with the
> Javadoc?
> 
> --
> Michael Mior
> mmior@uwaterloo.ca
> 
> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:
> 
>> A force-push to the “site” branch each release would not be a terrible
>> thing. (Force-pushes are only suspect when they are to the master branch or
>> a release branch.) Before the release, the release manager should make sure
>> that edits on “site" have made it to “master”. Right after the release,
>> they will deploy the site from the “site” branch, which almost certainly
>> means syncing “site" with “master”.
>> 
>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
>>> 
>>> Sounds reasonable to me. I like that better than the current approach of
>>> whoever is updating the site needing to maintain mental state on what is
>>> and isn't ready to be posted. We should of course add documentation for
>>> this as part of the release process. We also should make clear in the
>> site
>>> documentation that nothing should be committed to the site branch
>> directly,
>>> but only what is cherry picked from master. I might even suggest that the
>>> sync which happens during release be a force push of the current master
>> to
>>> the site branch, but I'm not sure I like that idea.
>>> 
>>> --
>>> Michael Mior
>>> mmior@uwaterloo.ca
>>> 
>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
>>> 
>>>> I am adding Kevin to the committers list, and I am seeing the problem of
>>>> mixed changes - recently Michael has edited the site to add two PMC
>>>> members, and Shuyi has added documentation for CREATE TYPE. We want the
>>>> former to appear on the site, but the latter should wait until the
>> release.
>>>> 
>>>> I propose to create a “site” git branch that cherry-picks changes that
>> we
>>>> wish to have appear on the site immediately.
>>>> 
>>>> On each release, it would be in sync with master, but might start to
>>>> differ when we add documentation for features. It would sync up on the
>> next
>>>> release.
>>>> 
>>>> Any comments/objections?
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>> 
>>>>> You are right. Thanks a lot for the explanation, Julian.
>>>>> 
>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
>> wrote:
>>>>> 
>>>>>> I think it’s misleading to end-users if the web site contains features
>>>>>> that have not yet been released. So, we aim to re-generate the web
>> site
>>>>>> just after a release. (For non product-related stuff, such as
>> committers
>>>>>> and upcoming talks, we change the web site continuously. The person
>>>>>> maintaining the web site has to be a bit careful not to publish the
>>>> wrong
>>>>>> stuff.)
>>>>>> 
>>>>>> 
>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>>>> 
>>>>>>> @Julian, thanks for reviewing the code. I think we need to regenerate
>>>> the
>>>>>>> website as well so that it contains the latest documentation on type
>>>>>>> collection and type DDLs. Let me know how I can help.
>>>>>>> 
>>>>>>> @Valli, with the latest master, you should be able to either use
>> CREATE
>>>>>>> TYPE statement to define your own type or define your new type in the
>>>>>> JSON
>>>>>>> schema.
>>>>>>> 
>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
>>>> wrote:
>>>>>>> 
>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
>> anything.
>>>>>>>> 
>>>>>>>> shuyi
>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
>> wrote:
>>>>>>>> 
>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi)
>>>> but
>>>>>> I
>>>>>>>>> reviewed it yesterday and am currently testing, so it should be
>>>>>> committed
>>>>>>>>> to master shortly.
>>>>>>>>> 
>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Currently, user defined type is not supported in Calcite. But it's
>>>>>> WIP,
>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045.
>> With
>>>>>>>>> this
>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your own
>> type
>>>>>> or
>>>>>>>>>> define your new type in the JSON schema.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Shuyi
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>>>>>>>> aishwaryaanns@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'. For
>>>>>>>>>>> example, select
>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
>>>> showing,
>>>>>>>>>>> Unknown data type name 'TEXT'.
>>>>>>>>>>> 
>>>>>>>>>>> How can I make calcite to parse the above query successfully
>> having
>>>>>>>>>>> user-defined data type 'text'?
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks in advance
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>>>> future."
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>> future."
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>> future."
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> "So you have to trust that the dots will somehow connect in your
>> future."
>>>> 
>>>> 
>> 
>>

Re: How to create user-defined data types in calcite?

Posted by Michael Mior <mm...@uwaterloo.ca>.

Sure. Although there (at least) two ways of syncing site with master. One
being to force push master to the site branch and the other to merge the
master branch into site. I do kind of like the idea of the force push just
to avoid having the site branch be eternally filled with a bunch of merge
commits.

One thing that didn't immediately occur to me is what happens with the
Javadoc?

--
Michael Mior
mmior@uwaterloo.ca

2018-04-25 13:30 GMT-04:00 Julian Hyde <jh...@apache.org>:

> A force-push to the “site” branch each release would not be a terrible
> thing. (Force-pushes are only suspect when they are to the master branch or
> a release branch.) Before the release, the release manager should make sure
> that edits on “site" have made it to “master”. Right after the release,
> they will deploy the site from the “site” branch, which almost certainly
> means syncing “site" with “master”.
>
> > On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> >
> > Sounds reasonable to me. I like that better than the current approach of
> > whoever is updating the site needing to maintain mental state on what is
> > and isn't ready to be posted. We should of course add documentation for
> > this as part of the release process. We also should make clear in the
> site
> > documentation that nothing should be committed to the site branch
> directly,
> > but only what is cherry picked from master. I might even suggest that the
> > sync which happens during release be a force push of the current master
> to
> > the site branch, but I'm not sure I like that idea.
> >
> > --
> > Michael Mior
> > mmior@uwaterloo.ca
> >
> > 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
> >
> >> I am adding Kevin to the committers list, and I am seeing the problem of
> >> mixed changes - recently Michael has edited the site to add two PMC
> >> members, and Shuyi has added documentation for CREATE TYPE. We want the
> >> former to appear on the site, but the latter should wait until the
> release.
> >>
> >> I propose to create a “site” git branch that cherry-picks changes that
> we
> >> wish to have appear on the site immediately.
> >>
> >> On each release, it would be in sync with master, but might start to
> >> differ when we add documentation for features. It would sync up on the
> next
> >> release.
> >>
> >> Any comments/objections?
> >>
> >> Julian
> >>
> >>
> >>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>
> >>> You are right. Thanks a lot for the explanation, Julian.
> >>>
> >>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org>
> wrote:
> >>>
> >>>> I think it’s misleading to end-users if the web site contains features
> >>>> that have not yet been released. So, we aim to re-generate the web
> site
> >>>> just after a release. (For non product-related stuff, such as
> committers
> >>>> and upcoming talks, we change the web site continuously. The person
> >>>> maintaining the web site has to be a bit careful not to publish the
> >> wrong
> >>>> stuff.)
> >>>>
> >>>>
> >>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>>>
> >>>>> @Julian, thanks for reviewing the code. I think we need to regenerate
> >> the
> >>>>> website as well so that it contains the latest documentation on type
> >>>>> collection and type DDLs. Let me know how I can help.
> >>>>>
> >>>>> @Valli, with the latest master, you should be able to either use
> CREATE
> >>>>> TYPE statement to define your own type or define your new type in the
> >>>> JSON
> >>>>> schema.
> >>>>>
> >>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Thanks a lot for your time , Julian. Let me know if you need
> anything.
> >>>>>>
> >>>>>> shuyi
> >>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org>
> wrote:
> >>>>>>
> >>>>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi)
> >> but
> >>>> I
> >>>>>>> reviewed it yesterday and am currently testing, so it should be
> >>>> committed
> >>>>>>> to master shortly.
> >>>>>>>
> >>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>> Currently, user defined type is not supported in Calcite. But it's
> >>>> WIP,
> >>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045.
> With
> >>>>>>> this
> >>>>>>>> PR, you can either use CREATE TYPE statement to define your own
> type
> >>>> or
> >>>>>>>> define your new type in the JSON schema.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Shuyi
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>>>> aishwaryaanns@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I want to parse a query having 'text' in place of 'varchar'. For
> >>>>>>>>> example, select
> >>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
> >> showing,
> >>>>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>>>
> >>>>>>>>> How can I make calcite to parse the above query successfully
> having
> >>>>>>>>> user-defined data type 'text'?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks in advance
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>>> future."
> >>>>>>>
> >>>>>>> --
> >>>>>> "So you have to trust that the dots will somehow connect in your
> >>>> future."
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> "So you have to trust that the dots will somehow connect in your
> >> future."
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> "So you have to trust that the dots will somehow connect in your
> future."
> >>
> >>
>
>

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

A force-push to the “site” branch each release would not be a terrible thing. (Force-pushes are only suspect when they are to the master branch or a release branch.) Before the release, the release manager should make sure that edits on “site" have made it to “master”. Right after the release, they will deploy the site from the “site” branch, which almost certainly means syncing “site" with “master”.

> On Apr 25, 2018, at 10:24 AM, Michael Mior <mm...@uwaterloo.ca> wrote:
> 
> Sounds reasonable to me. I like that better than the current approach of
> whoever is updating the site needing to maintain mental state on what is
> and isn't ready to be posted. We should of course add documentation for
> this as part of the release process. We also should make clear in the site
> documentation that nothing should be committed to the site branch directly,
> but only what is cherry picked from master. I might even suggest that the
> sync which happens during release be a force push of the current master to
> the site branch, but I'm not sure I like that idea.
> 
> --
> Michael Mior
> mmior@uwaterloo.ca
> 
> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:
> 
>> I am adding Kevin to the committers list, and I am seeing the problem of
>> mixed changes - recently Michael has edited the site to add two PMC
>> members, and Shuyi has added documentation for CREATE TYPE. We want the
>> former to appear on the site, but the latter should wait until the release.
>> 
>> I propose to create a “site” git branch that cherry-picks changes that we
>> wish to have appear on the site immediately.
>> 
>> On each release, it would be in sync with master, but might start to
>> differ when we add documentation for features. It would sync up on the next
>> release.
>> 
>> Any comments/objections?
>> 
>> Julian
>> 
>> 
>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
>>> 
>>> You are right. Thanks a lot for the explanation, Julian.
>>> 
>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org> wrote:
>>> 
>>>> I think it’s misleading to end-users if the web site contains features
>>>> that have not yet been released. So, we aim to re-generate the web site
>>>> just after a release. (For non product-related stuff, such as committers
>>>> and upcoming talks, we change the web site continuously. The person
>>>> maintaining the web site has to be a bit careful not to publish the
>> wrong
>>>> stuff.)
>>>> 
>>>> 
>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>> 
>>>>> @Julian, thanks for reviewing the code. I think we need to regenerate
>> the
>>>>> website as well so that it contains the latest documentation on type
>>>>> collection and type DDLs. Let me know how I can help.
>>>>> 
>>>>> @Valli, with the latest master, you should be able to either use CREATE
>>>>> TYPE statement to define your own type or define your new type in the
>>>> JSON
>>>>> schema.
>>>>> 
>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
>> wrote:
>>>>> 
>>>>>> Thanks a lot for your time , Julian. Let me know if you need anything.
>>>>>> 
>>>>>> shuyi
>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
>>>>>> 
>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi)
>> but
>>>> I
>>>>>>> reviewed it yesterday and am currently testing, so it should be
>>>> committed
>>>>>>> to master shortly.
>>>>>>> 
>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Currently, user defined type is not supported in Calcite. But it's
>>>> WIP,
>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. With
>>>>>>> this
>>>>>>>> PR, you can either use CREATE TYPE statement to define your own type
>>>> or
>>>>>>>> define your new type in the JSON schema.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> Shuyi
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>>>>>> aishwaryaanns@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'. For
>>>>>>>>> example, select
>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
>> showing,
>>>>>>>>> Unknown data type name 'TEXT'.
>>>>>>>>> 
>>>>>>>>> How can I make calcite to parse the above query successfully having
>>>>>>>>> user-defined data type 'text'?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks in advance
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>>>> future."
>>>>>>> 
>>>>>>> --
>>>>>> "So you have to trust that the dots will somehow connect in your
>>>> future."
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> "So you have to trust that the dots will somehow connect in your
>> future."
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> "So you have to trust that the dots will somehow connect in your future."
>> 
>>

Re: How to create user-defined data types in calcite?

Posted by Michael Mior <mm...@uwaterloo.ca>.

Sounds reasonable to me. I like that better than the current approach of
whoever is updating the site needing to maintain mental state on what is
and isn't ready to be posted. We should of course add documentation for
this as part of the release process. We also should make clear in the site
documentation that nothing should be committed to the site branch directly,
but only what is cherry picked from master. I might even suggest that the
sync which happens during release be a force push of the current master to
the site branch, but I'm not sure I like that idea.

--
Michael Mior
mmior@uwaterloo.ca

2018-04-25 12:52 GMT-04:00 Julian Hyde <jh...@apache.org>:

> I am adding Kevin to the committers list, and I am seeing the problem of
> mixed changes - recently Michael has edited the site to add two PMC
> members, and Shuyi has added documentation for CREATE TYPE. We want the
> former to appear on the site, but the latter should wait until the release.
>
> I propose to create a “site” git branch that cherry-picks changes that we
> wish to have appear on the site immediately.
>
> On each release, it would be in sync with master, but might start to
> differ when we add documentation for features. It would sync up on the next
> release.
>
> Any comments/objections?
>
> Julian
>
>
> > On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
> >
> > You are right. Thanks a lot for the explanation, Julian.
> >
> > On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org> wrote:
> >
> >> I think it’s misleading to end-users if the web site contains features
> >> that have not yet been released. So, we aim to re-generate the web site
> >> just after a release. (For non product-related stuff, such as committers
> >> and upcoming talks, we change the web site continuously. The person
> >> maintaining the web site has to be a bit careful not to publish the
> wrong
> >> stuff.)
> >>
> >>
> >>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>
> >>> @Julian, thanks for reviewing the code. I think we need to regenerate
> the
> >>> website as well so that it contains the latest documentation on type
> >>> collection and type DDLs. Let me know how I can help.
> >>>
> >>> @Valli, with the latest master, you should be able to either use CREATE
> >>> TYPE statement to define your own type or define your new type in the
> >> JSON
> >>> schema.
> >>>
> >>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com>
> wrote:
> >>>
> >>>> Thanks a lot for your time , Julian. Let me know if you need anything.
> >>>>
> >>>> shuyi
> >>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
> >>>>
> >>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi)
> but
> >> I
> >>>>> reviewed it yesterday and am currently testing, so it should be
> >> committed
> >>>>> to master shortly.
> >>>>>
> >>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>>>>
> >>>>>> Currently, user defined type is not supported in Calcite. But it's
> >> WIP,
> >>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. With
> >>>>> this
> >>>>>> PR, you can either use CREATE TYPE statement to define your own type
> >> or
> >>>>>> define your new type in the JSON schema.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Shuyi
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>> aishwaryaanns@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I want to parse a query having 'text' in place of 'varchar'. For
> >>>>>>> example, select
> >>>>>>> cast(ps_comment as text) from part While parsing calcite is
> showing,
> >>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>
> >>>>>>> How can I make calcite to parse the above query successfully having
> >>>>>>> user-defined data type 'text'?
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks in advance
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>> future."
> >>>>>
> >>>>> --
> >>>> "So you have to trust that the dots will somehow connect in your
> >> future."
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> "So you have to trust that the dots will somehow connect in your
> future."
> >>
> >>
> >
> >
> > --
> > "So you have to trust that the dots will somehow connect in your future."
>
>

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

I am adding Kevin to the committers list, and I am seeing the problem of mixed changes - recently Michael has edited the site to add two PMC members, and Shuyi has added documentation for CREATE TYPE. We want the former to appear on the site, but the latter should wait until the release.

I propose to create a “site” git branch that cherry-picks changes that we wish to have appear on the site immediately.

On each release, it would be in sync with master, but might start to differ when we add documentation for features. It would sync up on the next release.

Any comments/objections?

Julian


> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <su...@gmail.com> wrote:
> 
> You are right. Thanks a lot for the explanation, Julian.
> 
> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org> wrote:
> 
>> I think it’s misleading to end-users if the web site contains features
>> that have not yet been released. So, we aim to re-generate the web site
>> just after a release. (For non product-related stuff, such as committers
>> and upcoming talks, we change the web site continuously. The person
>> maintaining the web site has to be a bit careful not to publish the wrong
>> stuff.)
>> 
>> 
>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
>>> 
>>> @Julian, thanks for reviewing the code. I think we need to regenerate the
>>> website as well so that it contains the latest documentation on type
>>> collection and type DDLs. Let me know how I can help.
>>> 
>>> @Valli, with the latest master, you should be able to either use CREATE
>>> TYPE statement to define your own type or define your new type in the
>> JSON
>>> schema.
>>> 
>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com> wrote:
>>> 
>>>> Thanks a lot for your time , Julian. Let me know if you need anything.
>>>> 
>>>> shuyi
>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
>>>> 
>>>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but
>> I
>>>>> reviewed it yesterday and am currently testing, so it should be
>> committed
>>>>> to master shortly.
>>>>> 
>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>>>> 
>>>>>> Currently, user defined type is not supported in Calcite. But it's
>> WIP,
>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. With
>>>>> this
>>>>>> PR, you can either use CREATE TYPE statement to define your own type
>> or
>>>>>> define your new type in the JSON schema.
>>>>>> 
>>>>>> Thanks
>>>>>> Shuyi
>>>>>> 
>>>>>> 
>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>>>> aishwaryaanns@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I want to parse a query having 'text' in place of 'varchar'. For
>>>>>>> example, select
>>>>>>> cast(ps_comment as text) from part While parsing calcite is showing,
>>>>>>> Unknown data type name 'TEXT'.
>>>>>>> 
>>>>>>> How can I make calcite to parse the above query successfully having
>>>>>>> user-defined data type 'text'?
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks in advance
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> "So you have to trust that the dots will somehow connect in your
>>>>> future."
>>>>> 
>>>>> --
>>>> "So you have to trust that the dots will somehow connect in your
>> future."
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> "So you have to trust that the dots will somehow connect in your future."
>> 
>> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by Shuyi Chen <su...@gmail.com>.

You are right. Thanks a lot for the explanation, Julian.

On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jh...@apache.org> wrote:

> I think it’s misleading to end-users if the web site contains features
> that have not yet been released. So, we aim to re-generate the web site
> just after a release. (For non product-related stuff, such as committers
> and upcoming talks, we change the web site continuously. The person
> maintaining the web site has to be a bit careful not to publish the wrong
> stuff.)
>
>
> > On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
> >
> > @Julian, thanks for reviewing the code. I think we need to regenerate the
> > website as well so that it contains the latest documentation on type
> > collection and type DDLs. Let me know how I can help.
> >
> > @Valli, with the latest master, you should be able to either use CREATE
> > TYPE statement to define your own type or define your new type in the
> JSON
> > schema.
> >
> > On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com> wrote:
> >
> >> Thanks a lot for your time , Julian. Let me know if you need anything.
> >>
> >> shuyi
> >> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
> >>
> >>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but
> I
> >>> reviewed it yesterday and am currently testing, so it should be
> committed
> >>> to master shortly.
> >>>
> >>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
> >>>>
> >>>> Currently, user defined type is not supported in Calcite. But it's
> WIP,
> >>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. With
> >>> this
> >>>> PR, you can either use CREATE TYPE statement to define your own type
> or
> >>>> define your new type in the JSON schema.
> >>>>
> >>>> Thanks
> >>>> Shuyi
> >>>>
> >>>>
> >>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>> aishwaryaanns@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> I want to parse a query having 'text' in place of 'varchar'. For
> >>>>> example, select
> >>>>> cast(ps_comment as text) from part While parsing calcite is showing,
> >>>>> Unknown data type name 'TEXT'.
> >>>>>
> >>>>> How can I make calcite to parse the above query successfully having
> >>>>> user-defined data type 'text'?
> >>>>>
> >>>>>
> >>>>> Thanks in advance
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> "So you have to trust that the dots will somehow connect in your
> >>> future."
> >>>
> >>> --
> >> "So you have to trust that the dots will somehow connect in your
> future."
> >>
> >
> >
> >
> > --
> > "So you have to trust that the dots will somehow connect in your future."
>
>


-- 
"So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

I think it’s misleading to end-users if the web site contains features that have not yet been released. So, we aim to re-generate the web site just after a release. (For non product-related stuff, such as committers and upcoming talks, we change the web site continuously. The person maintaining the web site has to be a bit careful not to publish the wrong stuff.)
 

> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <su...@gmail.com> wrote:
> 
> @Julian, thanks for reviewing the code. I think we need to regenerate the
> website as well so that it contains the latest documentation on type
> collection and type DDLs. Let me know how I can help.
> 
> @Valli, with the latest master, you should be able to either use CREATE
> TYPE statement to define your own type or define your new type in the JSON
> schema.
> 
> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com> wrote:
> 
>> Thanks a lot for your time , Julian. Let me know if you need anything.
>> 
>> shuyi
>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
>> 
>>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but I
>>> reviewed it yesterday and am currently testing, so it should be committed
>>> to master shortly.
>>> 
>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
>>>> 
>>>> Currently, user defined type is not supported in Calcite. But it's WIP,
>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045. With
>>> this
>>>> PR, you can either use CREATE TYPE statement to define your own type or
>>>> define your new type in the JSON schema.
>>>> 
>>>> Thanks
>>>> Shuyi
>>>> 
>>>> 
>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>>> aishwaryaanns@gmail.com>
>>>> wrote:
>>>> 
>>>>> I want to parse a query having 'text' in place of 'varchar'. For
>>>>> example, select
>>>>> cast(ps_comment as text) from part While parsing calcite is showing,
>>>>> Unknown data type name 'TEXT'.
>>>>> 
>>>>> How can I make calcite to parse the above query successfully having
>>>>> user-defined data type 'text'?
>>>>> 
>>>>> 
>>>>> Thanks in advance
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> "So you have to trust that the dots will somehow connect in your
>>> future."
>>> 
>>> --
>> "So you have to trust that the dots will somehow connect in your future."
>> 
> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by .

Is the CREATE TYPE feature available with current master for sure?

On 2018/04/22 05:13:45, Shuyi Chen <su...@gmail.com> wrote: 
> @Julian, thanks for reviewing the code. I think we need to regenerate the
> website as well so that it contains the latest documentation on type
> collection and type DDLs. Let me know how I can help.
> 
> @Valli, with the latest master, you should be able to either use CREATE
> TYPE statement to define your own type or define your new type in the JSON
> schema.
> 
> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com> wrote:
> 
> > Thanks a lot for your time , Julian. Let me know if you need anything.
> >
> > shuyi
> > On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
> >
> >> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but I
> >> reviewed it yesterday and am currently testing, so it should be committed
> >> to master shortly.
> >>
> >> > On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
> >> >
> >> > Currently, user defined type is not supported in Calcite. But it's WIP,
> >> > please see https://issues.apache.org/jira/browse/CALCITE-2045. With
> >> this
> >> > PR, you can either use CREATE TYPE statement to define your own type or
> >> > define your new type in the JSON schema.
> >> >
> >> > Thanks
> >> > Shuyi
> >> >
> >> >
> >> > On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >> aishwaryaanns@gmail.com>
> >> > wrote:
> >> >
> >> >> I want to parse a query having 'text' in place of 'varchar'. For
> >> >> example, select
> >> >> cast(ps_comment as text) from part While parsing calcite is showing,
> >> >> Unknown data type name 'TEXT'.
> >> >>
> >> >> How can I make calcite to parse the above query successfully having
> >> >> user-defined data type 'text'?
> >> >>
> >> >>
> >> >> Thanks in advance
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > "So you have to trust that the dots will somehow connect in your
> >> future."
> >>
> >> --
> > "So you have to trust that the dots will somehow connect in your future."
> >
> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."
>

Re: How to create user-defined data types in calcite?

Posted by Shuyi Chen <su...@gmail.com>.

@Julian, thanks for reviewing the code. I think we need to regenerate the
website as well so that it contains the latest documentation on type
collection and type DDLs. Let me know how I can help.

@Valli, with the latest master, you should be able to either use CREATE
TYPE statement to define your own type or define your new type in the JSON
schema.

On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <su...@gmail.com> wrote:

> Thanks a lot for your time , Julian. Let me know if you need anything.
>
> shuyi
> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:
>
>> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but I
>> reviewed it yesterday and am currently testing, so it should be committed
>> to master shortly.
>>
>> > On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
>> >
>> > Currently, user defined type is not supported in Calcite. But it's WIP,
>> > please see https://issues.apache.org/jira/browse/CALCITE-2045. With
>> this
>> > PR, you can either use CREATE TYPE statement to define your own type or
>> > define your new type in the JSON schema.
>> >
>> > Thanks
>> > Shuyi
>> >
>> >
>> > On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
>> aishwaryaanns@gmail.com>
>> > wrote:
>> >
>> >> I want to parse a query having 'text' in place of 'varchar'. For
>> >> example, select
>> >> cast(ps_comment as text) from part While parsing calcite is showing,
>> >> Unknown data type name 'TEXT'.
>> >>
>> >> How can I make calcite to parse the above query successfully having
>> >> user-defined data type 'text'?
>> >>
>> >>
>> >> Thanks in advance
>> >>
>> >
>> >
>> >
>> > --
>> > "So you have to trust that the dots will somehow connect in your
>> future."
>>
>> --
> "So you have to trust that the dots will somehow connect in your future."
>



-- 
"So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by Shuyi Chen <su...@gmail.com>.

Thanks a lot for your time , Julian. Let me know if you need anything.

shuyi
On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jh...@apache.org> wrote:

> Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but I
> reviewed it yesterday and am currently testing, so it should be committed
> to master shortly.
>
> > On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
> >
> > Currently, user defined type is not supported in Calcite. But it's WIP,
> > please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
> > PR, you can either use CREATE TYPE statement to define your own type or
> > define your new type in the JSON schema.
> >
> > Thanks
> > Shuyi
> >
> >
> > On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> aishwaryaanns@gmail.com>
> > wrote:
> >
> >> I want to parse a query having 'text' in place of 'varchar'. For
> >> example, select
> >> cast(ps_comment as text) from part While parsing calcite is showing,
> >> Unknown data type name 'TEXT'.
> >>
> >> How can I make calcite to parse the above query successfully having
> >> user-defined data type 'text'?
> >>
> >>
> >> Thanks in advance
> >>
> >
> >
> >
> > --
> > "So you have to trust that the dots will somehow connect in your future."
>
> --
"So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by Julian Hyde <jh...@apache.org>.

Yes, I’ve ignored that change for a couple of months (sorry Shuyi) but I reviewed it yesterday and am currently testing, so it should be committed to master shortly.

> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <su...@gmail.com> wrote:
> 
> Currently, user defined type is not supported in Calcite. But it's WIP,
> please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
> PR, you can either use CREATE TYPE statement to define your own type or
> define your new type in the JSON schema.
> 
> Thanks
> Shuyi
> 
> 
> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <ai...@gmail.com>
> wrote:
> 
>> I want to parse a query having 'text' in place of 'varchar'. For
>> example, select
>> cast(ps_comment as text) from part While parsing calcite is showing,
>> Unknown data type name 'TEXT'.
>> 
>> How can I make calcite to parse the above query successfully having
>> user-defined data type 'text'?
>> 
>> 
>> Thanks in advance
>> 
> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."

Re: How to create user-defined data types in calcite?

Posted by .

Understood @Shuyi. Thank you

On 2018/04/21 00:41:23, Shuyi Chen <su...@gmail.com> wrote: 
> Currently, user defined type is not supported in Calcite. But it's WIP,
> please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
> PR, you can either use CREATE TYPE statement to define your own type or
> define your new type in the JSON schema.
> 
> Thanks
> Shuyi
> 
> 
> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <ai...@gmail.com>
> wrote:
> 
> > I want to parse a query having 'text' in place of 'varchar'. For
> > example, select
> > cast(ps_comment as text) from part While parsing calcite is showing,
> > Unknown data type name 'TEXT'.
> >
> > How can I make calcite to parse the above query successfully having
> > user-defined data type 'text'?
> >
> >
> > Thanks in advance
> >
> 
> 
> 
> -- 
> "So you have to trust that the dots will somehow connect in your future."
>

Re: How to create user-defined data types in calcite?

Posted by Shuyi Chen <su...@gmail.com>.

Currently, user defined type is not supported in Calcite. But it's WIP,
please see https://issues.apache.org/jira/browse/CALCITE-2045. With this
PR, you can either use CREATE TYPE statement to define your own type or
define your new type in the JSON schema.

Thanks
Shuyi

On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <ai...@gmail.com>
wrote:

> I want to parse a query having 'text' in place of 'varchar'. For
> example, select
> cast(ps_comment as text) from part While parsing calcite is showing,
> Unknown data type name 'TEXT'.
>
> How can I make calcite to parse the above query successfully having
> user-defined data type 'text'?
>
>
> Thanks in advance
>

-- 
"So you have to trust that the dots will somehow connect in your future."