Hi Sanja,
Since we have not officially started the coding period, I figured that an exercise in adding a parser syntax would be a good first step.
We can do automatic detection by looking at the cursor without to much extra work.
VicentiuOn Fri, 20 May 2016 at 08:29, Sanja <sanja.byelkin@gmail.com> wrote:Hi!
Have you read our discussion about automatic aggregate functions detection?
Am 20.05.2016 07:15 schrieb "Varun Gupta" <varungupta1803@gmail.com>:Hi,I have added the AGGREGATE keyword to the parser . Here is the link to the repository https://github.com/varunraiko/aggregate-functions .On Wed, May 18, 2016 at 9:50 PM, Sanja <sanja.byelkin@gmail.com> wrote:Hi!If we get it automatically then of course it should be done, but I doubts... We will see.On Wed, May 18, 2016 at 6:18 PM, Sergei Golubchik <serg@mariadb.org> wrote:Hi, Sanja!
On May 18, Sanja wrote:
> >
> > No, sorry, this doesn't work. It works for procedures, but not for
> > functions. See:
> >
> > CREATE FUNCTION f1 (a INT) RETURNS INT
> > BEGIN
> > RETURN SELECT f2(val) FROM t1 WHERE id=a;
> > END;
> >
> > CREATE FUNCTION f2 (b INT) RETURNS INT
> > BEGIN
> > ...
> > FETCH GROUP NEXT ROW;
> > ...
> > RETURN something;
> > END;
> >
> > Here, depending on what function is declared aggregate you will have
> > different results.
>
> I think in the first implementation we can have only one level
> functions. if we will have time we can then expand it for calls of
> other functions. But first the mechanism of temporary leaving then
> entering functions should be created (then it can be reused for
> recursive calls.
First implementation - may be (althought I don't understand why - this
requires no extra coding, nested function calls will just work
automatically). But the first implementation should not choose to use
the syntax that makes this extension impossible.
For example, Varun's project does not include window function support.
At all. But we will be able to add it later without redoing everything,
exising syntax can accomodate this new feature.