Re: DISCUSS: merge calcite-avatica and calcite repositories

[jincheng sun]

Second Vladimir's proposal // Generally speaking，we should decouple the
dependence of the two projects on the master branch, Of course, if you
merge into one repos, the issue of interdependence does not exist.

Best,
Jincheng Sun


Yogendra Sharma  于2021年11月9日周二 下午3:28写道：

> I agree with Vladimir.
>
> Although i am very new here but in my mind having one repository will
> reduce lot of efforts while not necessarily it will reduce flexibility and
> modularity of the the project.
>
> My initial impression is that we can achieve the same modularity
> constraints even after merging the code into one repo.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> 
> From: Vladimir Sitnikov 
> Sent: Tuesday, November 9, 2021, 12:38
> To: Apache Calcite dev list
> Subject: Re: DISCUSS: merge calcite-avatica and calcite repositories
>
> I know the below is too wordy, however, English is not my native language,
> so I tend to overexplain and duplicate thoughts.
>
> Julian>To allow separate communities
>
> This is something I do not understand.
> Let me be explicit: I am OK to maintain bits of avatica code when Calcite
> fixes overlap with Avatica for some reason (e.g. throwing exceptions).
> I am not OK with duplicating the same work just because someone else wants
> to have a separate repository.
>
> I was maintaining and releasing multiple (four!) repositories for pgjdbc
> when it was using Maven
> (Maven was not able to release jre6, jre7, and jre8 artifacts from within a
> single repository), and it was a big relief when the code was recollected
> into a single repository again.
>
> That is why I am advocating for merging avatica code back.
>
> Julian>Splitting code into modules makes it easier to continue to splitting
>
> I agree it is worth having calcite-core and avatica as separate jar
> artifacts.
> It is even worth splitting "enumerable" out of calcite-core into its own
> module.
> However, I do not see how splitting the repositories helps. I do not expect
> somebody to use calcite-avatica as a git submodule or something like that.
>
> Julian>to allow separate release schedules
>
> Here are the recent releases.
> There's often a pattern that "Calcite release follows Avatica release".
> It is even mentioned in the mails where someone suggests releasing Avatica,
> then releasing Calcite".
>
> A notable exception was rel/avatica-1.16.0 which was not connected to the
> release of Calcite.
> The rest Avatica releases seem to be quite close to Calcite releases, so I
> do not see what do we gain from "separate release schedules".
> It looks like co-locating the release would be easier for both maintenance
> overheads, testing, and consumption.
>
>
> 2016-03-16 rel/calcite-avatica-1.7.0
>
> 2016-03-17 calcite-1.7.0
>
> 2016-03-15 rel/calcite-avatica-1.7.1
>
> 2016-06-01 rel/calcite-avatica-1.8.0
>
> 2016-06-08 calcite-1.8.0
>
>
> 2016-09-17 calcite-1.9.0
>
>
> 2016-10-07 calcite-1.10.0
>
> 2016-10-27 rel/calcite-avatica-1.9.0
>
>
> 2017-01-03 calcite-1.11.0
>
> 2017-03-20 calcite-1.12.0
>
> 2017-05-23 rel/avatica-1.10.0
>
> 2017-06-22 calcite-1.13.0
>
>
> 2017-09-27 calcite-1.14.0
>
> 2017-12-05 calcite-1.15.0
>
> 2018-03-06 rel/avatica-1.11.0
>
> 2018-03-14 calcite-1.16.0
>
> 2018-06-21 rel/avatica-1.12.0
>
> 2018-07-16 calcite-1.17.0
>
> 2018-11-29 rel/avatica-1.13.0
>
> 2018-12-18 calcite-1.18.0
>
> 2019-03-20 calcite-1.19.0
>
> 2019-04-25 rel/avatica-1.14.0
>
> 2019-05-09 rel/avatica-1.15.0
>
> 2019-06-19 calcite-1.20.0
>
>
> 2019-09-06 calcite-1.21.0
>
> 2019-12-19 rel/avatica-1.16.0
>
>
> 2020-05-23 calcite-1.23.0
>
> 2020-06-22 rel/avatica-1.17.0
>
> 2020-07-23 calcite-1.24.0
> 2020-08-22 calcite-1.25.0
>
> 2020-10-06 calcite-1.26.0
>
>
> 2021-05-18 rel/avatica-1.18.0
>
> 2021-06-03 calcite-1.27.0
>
> 2021-10-04 rel/avatica-1.19.0
>
> 2021-10-19 calcite-1.28.0
>
> Julian>The last of these was particularly on my mind when we split Avatica
> from
> Calcite.
> Julian>I was pleased to see, for example, Apache Phoenix using Avatica
> successfully
> (including building an ODBC driver)
>
> Does it really help Phonenix that we split repositories?
> I am sure they should not really depend on the repositories.
> How would their life be harder if we release the same set of artifacts and
> jars from a single source tree?
>
> Julian>If Avatica had remained part of Calcite, both written in Java and
> using the same build system and release process,
> Julian>it’s less likely that Avatic

Re: [ANNOUNCE] Danny Chan joins Calcite PMC

[jincheng sun]

Congratulations Danny! Well deserved!

Best,
Jincheng

Enrico Olivelli  于2019年11月5日周二 下午2:31写道：

> Congrat Danny !
>
> Enrico
>
> Il giorno dom 3 nov 2019 alle ore 20:29 Julian Feinauer <
> j.feina...@pragmaticminds.de> ha scritto:
>
> > Congratulations Danny! Very well deserved!
> >
> > Julian
> >
> > Am 01.11.19, 20:49 schrieb "Muhammad Gelbana" :
> >
> > Congratulations!
> >
> > Thanks,
> > Gelbana
> >
> >
> > On Fri, Nov 1, 2019 at 9:07 AM Stamatis Zampetakis <
> zabe...@gmail.com>
> > wrote:
> >
> > > Congratulations Danny!
> > >
> > > You are doing an amazing job. The project and the community is
> > becoming
> > > better every day and your help is much appreciated.
> > >
> > > Keep up the momentum!
> > >
> > > Best,
> > > Stamatis
> > >
> > > On Thu, Oct 31, 2019 at 4:41 AM Kurt Young 
> wrote:
> > >
> > > > Congratulations Danny!
> > > >
> > > > Best,
> > > > Kurt
> > > >
> > > >
> > > > On Thu, Oct 31, 2019 at 11:18 AM Danny Chan <
> yuzhao@gmail.com>
> > > wrote:
> > > >
> > > > > Thank you so much colleagues, it’s my honor to work with you!
> > > > >
> > > > > I have always felt respected and the harmony of the community,
> > hope to
> > > > > contribute more and I would give help as best as I can, thanks
> !
> > > > >
> > > > > Best,
> > > > > Danny Chan
> > > > > 在 2019年10月31日 +0800 AM5:22，Francis Chuang <
> > francischu...@apache.org
> > > >，写道：
> > > > > > I'm pleased to announce that Danny has accepted an invitation
> > to
> > > > > > join the Calcite PMC. Danny has been a consistent and helpful
> > > > > > figure in the Calcite community for which we are very
> > grateful. We
> > > > > > look forward to the continued contributions and support.
> > > > > >
> > > > > > Please join me in congratulating Danny!
> > > > > >
> > > > > > - Francis (on behalf of the Calcite PMC)
> > > > >
> > > >
> > >
> >
> >
> >
>

Re: [DISCUSS] [Calcite-2683] ProjectMergeRule should not be performed when Nondeterministic udf has been referenced more than once

[jincheng sun]

Hi Hequn,
Thanks for report this issue. I think the premise of rule optimization is
to guarantee the correctness of the semantics. When the rule is matched,
the isDeterministics attribute of UDF must be considered.

+1 to be fixed.

Thanks,
Jincheng

Hequn Cheng  于2018年11月19日周一 下午11:52写道：

> Hi,
>
> Currently, there are some merge rules for Project, such as CalcMergeRule,
> ProjectMergeRule, and ProjectCalcMergeRule. I found that these merge rules
> should not be performed when Nondeterministic expression of the
> bottom(inner) project has been referenced more than once by the top(outer)
> project. Take the following test as an example:
>
>   @Test public void testProjectMergeCalcMergeWithNonDeterministic() throws
> Exception {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(FilterProjectTransposeRule.INSTANCE)
> .addRuleInstance(ProjectMergeRule.INSTANCE)
> .build();
>
> checkPlanning(program,
> "select name, a as a1, a as a2 from (\n"
> + "  select *, rand() as a\n"
> + "  from dept)\n"
> + "where deptno = 10\n");
>   }
>
> The first select generates `a` from `rand()` and the second select generate
> `a1` and `a2` from `a`. From the SQL, `a1` should equal to `a2`.
> Let's take a look at the result plan:
>
> LogicalProject(NAME=[$1], A1=[RAND()], A2=[RAND()])
>   LogicalFilter(condition=[=($0, 10)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
>
> In the plan, a1 may not equal to a2 due to the projects merge which is
> against the SQL(a1 equals to a2).
> In order to let a1 equal to a2, one option to solve the problem is to
> disable these merge rules in such cases, so that the result plan will be:
>
> LogicalProject(NAME=[$1], A1=[$2], A2=[$2])
>   LogicalProject(DEPTNO=[$0], NAME=[$1], A=[RAND()])
> LogicalFilter(condition=[=($0, 10)])
>   LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
>
> Do you guys have any good ideas or encountered similar problems? Any
> suggestions are greatly appreciated.
>
> Best,
> Hequn
>
> [1] jira link: https://issues.apache.org/jira/browse/CALCITE-2683
>

Re: Why not optimize the parameters of COUNT (1) in OVER window ？

[jincheng sun]

Thanks @Julian, I have opened a JIRA.
https://issues.apache.org/jira/browse/CALCITE-2126

Best, Jincheng

2018-01-09 5:47 GMT+08:00 Julian Hyde <jh...@apache.org>:

> I agree, this would be a good optimization. Please log a JIRA case for it.
>
> The only reason we don’t do it now is because the code path for creating
> regular aggregates (e.g. “select count(x) from t”) is different than the
> code path for creating windowed aggregates (e.g. “select count(x) over (…)
> from t”).
>
> Probably you should add the optimization to RexBuilder.makeOver, so at
> least it is happening at the same time as RexBuilder.addAggCall. Add tests
> to SqlToRelConverterTest. In your tests, make sure that “avg(x) over w” is
> translated to “sum(x) over w / count(*) over w” if “x” is NOT NULL; we make
> that optimization in non-windowed AVG, and it is a useful one.
>
> Julian
>
>
>
> On Jan 7, 2018, at 4:00 AM, jincheng sun <sunjincheng...@gmail.com> wrote:
>
> Hi Julian,
>
> I'm a bit confused by the different optimization of COUNT (1) in OVER
> window and tumble window.
>
> When we parse a SQL:
>
> select COUNT(1) from T tumble(rowtime, interval 2 seconds)
>
>  In RexBuild.addAggCall will do the optimize as follows:
>
> if(aggCall.getAggregation() instanceof SqlCountAggFunction && 
> !aggCall.isDistinct()) {
> List rex = aggCall.getArgList();
> List index = nullableArgs(rex, aggArgTypes);
> if(!index.equals(rex)) {
> aggCall = aggCall.copy(index, aggCall.filterArg);
> }
> }
>
> After the code logic above, the COUNT(1) -> COUNT().
>
> But when we parser a SQL:
>
> select COUNT(1) OVER(...) from T.
>
> we do not do the optimize, So, I want to know why not optimize the parameter 
> of COUNT (1) in OVER window?
>
> If we need do the optimize, can we do the optimize after SqlToRelConverter?
>
>
> Best, Jincheng
>
>
>
>

Re: [ANNOUNCE] New committer: Volodymyr Vysotskyi

[jincheng sun]

Congratulations, Vova ！

Vova Vysotskyi 于2017年12月23日 周六20:46写道：

> Thanks everyone for kind words!
> It is a great honour for me to become a Calcite committer and I am looking
> forward to making more contributions in future.
>
> A little bit about myself:
> As Julian has noticed, I am working for a Drill and currently, Roman Kulyk
> and I are working on the rebasing Drill onto the latest Calcite release.
> We very close to finish this task - there are left only a few issues.
> Also, I am obsessed with physics and mathematics.
>
> Kind regards,
> Volodymyr Vysotskyi
>
> On 2017-12-22 10:40, Vitalii Diravka  wrote:
> > Good news!
> >
> > Congratulations, Vova!
> >
> > Kind regards
> > Vitalii
> >
> > On Fri, Dec 22, 2017 at 8:53 AM, Arina Ielchiieva 
> wrote:
> >
> > > Congratulations, Vova! Well deserved.
> > >
> > > Kind regards
> > > Arina
> > >
> > > On Fri, Dec 22, 2017 at 5:01 AM, Zhiqiang He 
> > > wrote:
> > >
> > > > Congratulations and Welcome!
> > > >
> > > > Regards
> > > > James
> > > >
> > > > 
> > > > From: Julian Hyde 
> > > > Sent: Friday, December 22, 2017 07:45
> > > > To: dev@calcite.apache.org
> > > > Cc: Vova Vysotskyi
> > > > Subject: [ANNOUNCE] New committer: Volodymyr Vysotskyi
> > > >
> > > > Apache Calcite's Project Management Committee (PMC) has invited
> Volodymyr
> > > > (Vova) Vysotskyi to become a committer, and we are pleased to
> announce
> > > that
> > > > he has accepted.
> > > >
> > > > Volodymyr has made a steady stream of high-quality contributions
> over the
> > > > past few months. I believe that he is is working to get Drill onto
> the
> > > > latest Calcite release. The improvements he has made to Calcite will
> help
> > > > Drill and many other users.
> > > >
> > > > Volodymr,
> > > >
> > > > Welcome, thank you for your contributions, and we look forward your
> > > > further interactions with the community!
> > > >
> > > > If you wish, please feel free to tell us more about yourself and
> what you
> > > > are working on.
> > > >
> > > > Julian (on behalf of the Apache Calcite PMC)
> > > >
> > > >
> > >
> >
>

Re: Do we need support % in select clause?

[jincheng sun]

Thanks Julian. I'll file a JIRA. -:)

Thanks, Jincheng

2017-07-18 3:16 GMT+08:00 Julian Hyde <jh...@apache.org>:

> It’s a similar situation to the “!=“ operator. The standard says “<>”, but
> several databases allow “!=“ as an alternative.
>
> (There seems to be a common goal to make SQL look more like C. Whereas its
> original designers, IBM, apparently wanted to make it look like COBOL or
> PL/1. Hmmm.)
>
> Calcite allows “!=“ if SqlConformance.isBangEqualAllowed() returns true
> (which is true in the LENIENT, ORACLE_10 and ORACLE_12 conformance
> settings)[1]. We could do something similar for “%”. Please log a JIRA
> case. Contributions welcome.
>
> Julian
>
> [1] https://issues.apache.org/jira/browse/CALCITE-1374 <
> https://issues.apache.org/jira/browse/CALCITE-1374>
>
>
> > On Jul 17, 2017, at 12:36 AM, jincheng sun <sunjincheng...@gmail.com>
> wrote:
> >
> > Hi guys,
> >
> >  Currently the following sql is not supported.
> >
> >  SELECT a%3 FROM T
> >
> > * We get the exception:*
> >
> > Caused by: org.apache.calcite.sql.parser.SqlParseException: Lexical
> > error at line 1, column 9.  Encountered: "%" (37), after : ""
> > at
> > org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(
> SqlParserImpl.java:396)
> > at
> > org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(
> SqlParserImpl.java:129)
> >
> >
> > *The main reason is we do not add % as a operator token:*
> >
> > /* OPERATORS */
> >
> > <DEFAULT, DQID, BTID> TOKEN :
> > {
> >< EQ: "=" >
> > |   < GT: ">" >
> > |   < LT: "<" >
> > |   < HOOK: "?" >
> > |   < COLON: ":" >
> > |   < LE: "<=" >
> > |   < GE: ">=" >
> > |   < NE: "<>" >
> > |   < NE2: "!=" >
> > |   < PLUS: "+" >
> > |   < MINUS: "-" >
> > |   < STAR: "*" >
> > |   < SLASH: "/" >
> > |   < CONCAT: "||" >
> > |   < NAMED_ARGUMENT_ASSIGNMENT: "=>" >
> > |   < DOUBLE_PERIOD: ".." >
> > |   < QUOTE: "'" >
> > |   < DOUBLE_QUOTE: "\"" >
> > |   < VERTICAL_BAR: "|" >
> > |   < CARET: "^" >
> > |   < DOLLAR: "$" >
> > }
> >
> > In MySQL, SQL Server are supported. For Oracle, you have to use the
> > MOD function.
> >
> > So I'm not sure if calcite needs support, What do you think?
> >
> > Welcome anybody feedback. -:)
> >
> > Hope your opine. @Julian
> >
> > Best,
> >
> > Jincheng
>
>

Do we need support % in select clause?

[jincheng sun]

Hi guys,

  Currently the following sql is not supported.

  SELECT a%3 FROM T

* We get the exception:*

 Caused by: org.apache.calcite.sql.parser.SqlParseException: Lexical
error at line 1, column 9.  Encountered: "%" (37), after : ""
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:396)
at
org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:129)


*The main reason is we do not add % as a operator token:*

/* OPERATORS */

 TOKEN :
{
< EQ: "=" >
|   < GT: ">" >
|   < LT: "<" >
|   < HOOK: "?" >
|   < COLON: ":" >
|   < LE: "<=" >
|   < GE: ">=" >
|   < NE: "<>" >
|   < NE2: "!=" >
|   < PLUS: "+" >
|   < MINUS: "-" >
|   < STAR: "*" >
|   < SLASH: "/" >
|   < CONCAT: "||" >
|   < NAMED_ARGUMENT_ASSIGNMENT: "=>" >
|   < DOUBLE_PERIOD: ".." >
|   < QUOTE: "'" >
|   < DOUBLE_QUOTE: "\"" >
|   < VERTICAL_BAR: "|" >
|   < CARET: "^" >
|   < DOLLAR: "$" >
}

In MySQL, SQL Server are supported. For Oracle, you have to use the
MOD function.

So I'm not sure if calcite needs support, What do you think?

Welcome anybody feedback. -:)

Hope your opine. @Julian

Best,

Jincheng

Re: A question about calcite TIMESTAMPDIFF

[jincheng sun]

Thanks for your reply. You are right! DATEDIFF and TIMESTAMPDIFF are just
"similar" functions implemented by different DBs, and we do not have to
impose them as consistent. Now that I know they have a different reason,
it's enough for me. If one day we really need DATAADD / DIFF function,
DATEADD / DIFF and TIMESTAMPADD / DIFF can co-exist in calcite.

Thanks,
SunJIncheng

2017-06-10 2:02 GMT+08:00 Julian Hyde <jh...@apache.org>:

> I found this: https://stackoverflow.com/questions/26138167/is-
> timestampdiff-in-mysql-equivalent-to-datediff-in-sql-server
>
> We want Calcite's implementation of TIMESTAMPDIFF to be consistent
> with MySQL. If it's not, that's a bug in our TIMESTAMPDIFF. Frankly I
> don't want to think too much about these functions; I just want to be
> compatible with the "standard" implementations.
>
> If DATEDIFF and TIMESTAMPDIFF have different behavior, maybe we should
> re-visit https://issues.apache.org/jira/browse/CALCITE-1827 and
> implement DATEDIFF after all.
>
> Julian
>
> On Thu, Jun 8, 2017 at 10:54 PM, jincheng sun <sunjincheng...@gmail.com>
> wrote:
> > Hi, Julian,
> >   When I using TIMESTAMPDIFF, run the sql as follows:
> >
> > SELECT
> >  timestampdiff(WEEK, timestamp '2019-06-01 07:01:11',timestamp
> '2020-06-01
> > 07:01:11'),
> >  timestampdiff(WEEK, timestamp '2020-06-01 07:01:11',timestamp
> '2021-06-01
> > 07:01:11')
> >  FROM depts limit 1;
> >
> > I get the result : | 52 | 52 |
> >
> > And I check it in the MSSQL:
> >
> > SELECT
> >   datediff(WEEK, '2019-06-01 07:01:11','2020-06-01 07:01:11'),
> >   datediff(WEEK, '2020-06-01 07:01:11', '2021-06-01 07:01:11')
> > FROM stu;
> >
> > I get the result:  |53 |52
> >
> > As we know if the year starts on a week in a non-leap year, you end up
> with
> > 53 weeks. Or if either of the first two days lands on a week during a
> leap
> > year, then you can also get 53 weeks.
> >
> > So, I want to know why design `TIMESTAMPDIFF` as above logic. Please tell
> > me more about it.
> >
> > Thanks,
> > SunJincheng
>

Re: [ANNOUNCE] New committer: Zhiqiang He

[jincheng sun]

Congratulations.
SunJincheng

2017-06-10 6:16 GMT+08:00 Jesus Camacho Rodriguez :

> Congrats!
>
> -Jesús
>
>
>
>
> On 6/9/17, 9:11 PM, "Jinfeng Ni"  wrote:
>
> >Congratulations, Zhiqiang!
> >
> >
> >On Fri, Jun 9, 2017 at 1:00 PM, Jacques Nadeau 
> wrote:
> >
> >> Congrats, welcome!
> >>
> >> On Fri, Jun 9, 2017 at 12:57 PM, Eli Levine 
> wrote:
> >>
> >> > Congrats, Ransom! Keep up the good work.
> >> >
> >> > Eli
> >> >
> >> > On Fri, Jun 9, 2017 at 11:49 AM, Julian Hyde 
> wrote:
> >> > > Apache Calcite's Project Management Committee (PMC) has invited
> >> > > Zhiqiang He (Ransom) to become a committer, and we are pleased to
> >> > > announce that he has accepted.
> >> > >
> >> > > He has been quietly but steadily making contributions to add a
> >> > > MATCH_RECOGNIZE clause our SQL dialect, which ultimately will bring
> >> > > CEP (complex-event processing) capabilities to Flink and any other
> >> > > streaming engines that use Calcite SQL. He figured out how to add a
> >> > > major extension to SQL with minimal input, and his code
> contributions
> >> > > have been of high quality.
> >> > >
> >> > > Ransom,
> >> > >
> >> > > Welcome, thank you for your contributions, and we look forward your
> >> > > further interactions with the community!
> >> > >
> >> > > If you wish, please feel free to tell us more about yourself and
> what
> >> > > you are working on. Also, please let us know what name you would
> like
> >> > > us to address you by (Ransom, or something else).
> >> > >
> >> > > Julian (on behalf of the Apache Calcite PMC)
> >> >
> >>
>
>

A question about calcite TIMESTAMPDIFF

[jincheng sun]

Hi, Julian,
  When I using TIMESTAMPDIFF, run the sql as follows:

SELECT
 timestampdiff(WEEK, timestamp '2019-06-01 07:01:11',timestamp '2020-06-01
07:01:11'),
 timestampdiff(WEEK, timestamp '2020-06-01 07:01:11',timestamp '2021-06-01
07:01:11')
 FROM depts limit 1;

I get the result : | 52 | 52 |

And I check it in the MSSQL:

SELECT
  datediff(WEEK, '2019-06-01 07:01:11','2020-06-01 07:01:11'),
  datediff(WEEK, '2020-06-01 07:01:11', '2021-06-01 07:01:11')
FROM stu;

I get the result:  |53 |52

As we know if the year starts on a week in a non-leap year, you end up with
53 weeks. Or if either of the first two days lands on a week during a leap
year, then you can also get 53 weeks.

So, I want to know why design `TIMESTAMPDIFF` as above logic. Please tell
me more about it.

Thanks,
SunJincheng

Re: Why the user can not set `requiresOrder` and `requiresOver` in the `SqlUserDefinedAggFunction`

[jincheng sun]

Thanks @Julian. I have opened the PR.
https://github.com/apache/calcite/pull/446

Best,
SunJincheng

2017-05-10 5:46 GMT+08:00 Julian Hyde <jh...@apache.org>:

> Thanks. I’ve assigned it to you.
>
> > On May 9, 2017, at 1:43 AM, jincheng sun <sunjincheng...@gmail.com>
> wrote:
> >
> > Hi Julian,
> > Thanks for your reply. I had created a JIRA.
> > https://issues.apache.org/jira/browse/CALCITE-1780  I appreciated If you
> > can assign it to me. Or or give me the permission.
> >
> > Thanks,
> > SunJincheng
> >
> > 2017-05-09 5:17 GMT+08:00 Julian Hyde <jh...@apache.org>:
> >
> >> In fixing https://issues.apache.org/jira/browse/CALCITE-1327 <
> >> https://issues.apache.org/jira/browse/CALCITE-1327> we just didn’t add
> >> those 2 parameters to SqlUserDefinedAggFunction’s constructor. Feel
> free to
> >> add them. Of course you’ll need to ensure backwards compatibility and to
> >> write some tests.
> >>
> >>> On May 8, 2017, at 4:07 AM, jincheng sun <sunjincheng...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Julian，
> >>>  I have a question that need your help. The problem is described below:
> >>>  org.apache.calcite.sql.validate.SqlUserDefinedAggFunction calls the
> >> constructor of SqlAggFunction:
> >>>
> >>> Protected SqlAggFunction (
> >>>   String name,
> >>>   SqlIdentifier sqlIdentifier,
> >>>   SqlKind kind,
> >>>   SqlReturnTypeInference returnTypeInference,
> >>>   SqlOperandTypeInference operandTypeInference,
> >>>   SqlOperandTypeChecker operandTypeChecker,
> >>>   SqlFunctionCategory funcType,
> >>>   Boolean requiresOrder,
> >>>   Boolean requiresOver)
> >>>
> >>> The requiresOrder = false, requiresOver = false. as follow:
> >>>
> >>> Public SqlUserDefinedAggFunction (SqlIdentifier opName,
> >>>   SqlReturnTypeInference returnTypeInference,
> >>>   SqlOperandTypeInference operandTypeInference,
> >>>   SqlOperandTypeChecker operandTypeChecker, AggregateFunction
> >> function) {
> >>> Super (Util.last (opName.names), opName, SqlKind.OTHER_FUNCTION,
> >>> ReturnTypeInference, operandTypeInference, operandTypeChecker,
> >>> SqlFunctionCategory.USER_DEFINED_FUNCTION, false, false);
> >>> This.function = function;
> >>>   }
> >>>
> >>> I appreciated If you can tell me why the user can not set
> >> `requiresOrder` and `requiresOver`  in the `SqlUserDefinedAggFunction` ?
> >>>
> >>> Best,
> >>> SunJincheng
> >>
> >>
>
>

Re: Why the user can not set `requiresOrder` and `requiresOver` in the `SqlUserDefinedAggFunction`

[jincheng sun]

Hi Julian,
 Thanks for your reply. I had created a JIRA.
https://issues.apache.org/jira/browse/CALCITE-1780  I appreciated If you
can assign it to me. Or or give me the permission.

Thanks,
SunJincheng

2017-05-09 5:17 GMT+08:00 Julian Hyde <jh...@apache.org>:

> In fixing https://issues.apache.org/jira/browse/CALCITE-1327 <
> https://issues.apache.org/jira/browse/CALCITE-1327> we just didn’t add
> those 2 parameters to SqlUserDefinedAggFunction’s constructor. Feel free to
> add them. Of course you’ll need to ensure backwards compatibility and to
> write some tests.
>
> > On May 8, 2017, at 4:07 AM, jincheng sun <sunjincheng...@gmail.com>
> wrote:
> >
> > Hi Julian，
> >   I have a question that need your help. The problem is described below:
> >   org.apache.calcite.sql.validate.SqlUserDefinedAggFunction calls the
> constructor of SqlAggFunction:
> >
> > Protected SqlAggFunction (
> >String name,
> >SqlIdentifier sqlIdentifier,
> >SqlKind kind,
> >SqlReturnTypeInference returnTypeInference,
> >SqlOperandTypeInference operandTypeInference,
> >SqlOperandTypeChecker operandTypeChecker,
> >SqlFunctionCategory funcType,
> >Boolean requiresOrder,
> >Boolean requiresOver)
> >
> > The requiresOrder = false, requiresOver = false. as follow:
> >
> > Public SqlUserDefinedAggFunction (SqlIdentifier opName,
> >SqlReturnTypeInference returnTypeInference,
> >SqlOperandTypeInference operandTypeInference,
> >SqlOperandTypeChecker operandTypeChecker, AggregateFunction
> function) {
> >  Super (Util.last (opName.names), opName, SqlKind.OTHER_FUNCTION,
> >  ReturnTypeInference, operandTypeInference, operandTypeChecker,
> >  SqlFunctionCategory.USER_DEFINED_FUNCTION, false, false);
> >  This.function = function;
> >}
> >
> > I appreciated If you can tell me why the user can not set
> `requiresOrder` and `requiresOver`  in the `SqlUserDefinedAggFunction` ?
> >
> > Best,
> > SunJincheng
>
>