maria-developers team mailing list archive

[Varun Gupta <varungupta1803@xxxxxxxxx>]

Hi,
Regarding the plan for pausing and restarting the execution of the function
when we have to fetch a row,
1) is that we escape from the function when we come across a FETCH GROUP
statement , a state could be defined in thd->lex->sphead which would tell
that the function is paused and then we proceed with fetching the next row .
2) After we fetch the next row we return to the function and change the
state to running and then with the help of instruction pointer fetch the
next instruction to be executed .
3) We continue with this as long as their are rows available to be fetched.
As soon as there are no more rows available we return the result for the
aggregate function.

This is the basic design of what I am thinking and now I am going through
the code to see where all do I have to add code to get the desired results
:) .


On Tue, May 24, 2016 at 3:15 PM, Sanja <sanja.byelkin@xxxxxxxxx> wrote:

> Hi!
>
> I reviewed yet another time the code and have following toughts:
>
> a) if we store the tag separately (like deterministic or not) then
> separate field is better
>
> b) If we get the value form function content then flag is what we need.
>
> for now we are going by a) i.e. we clearly in the header of the function
> state that it is aggregate function independently of the function body.
>
>
> The other question where to store the tag:
>
> a) to have different type (function/procedure/trigger/aggregate function)
> b) to add new field
> c) use deterministic fiield
>
> a) IMHO it is bad way, at the moment we find the fucntion name we know
> that it is function name and nothing more
> b) good way, also require adding upgrade procedure
> c) a bit confusing and alsi we probably could have aggregate
> non-deterministic functions
>
>
> On Tue, May 24, 2016 at 10:59 AM, Vicențiu Ciorbaru <cvicentiu@xxxxxxxxx>
> wrote:
>
>> Hi Varun,
>>
>> I've reviewed your patch. Looks good from my side. Just stylistic
>> comments. Feel free to keep your own version if you don't agree with them.
>>
>> I think that you could have used the m_flags field, but having a specific
>> member makes things a lot clearer in my opinion. Perhaps Sanja has a
>> different opinion.
>>
>> Next step is to figure out how to use this new flag from sp_head in the
>> execution part. If you get completely stuck, let us know. :)
>>
>> Vicentiu
>>
>> On Tue, 24 May 2016 at 11:30 Sanja <sanja.byelkin@xxxxxxxxx> wrote:
>>
>>> Yes, the decision is right. I'll check later the code on github.
>>>
>>> On Tue, May 24, 2016 at 10:27 AM, Varun Gupta <varungupta1803@xxxxxxxxx>
>>> wrote:
>>>
>>>> Hi,
>>>> I had been going through the LEX struct and could not find any flag
>>>> member there which could be used to specify if a function is aggregate or
>>>> not. So i created the new flag inside sp_head, so as to make sure it could
>>>> be used for stored procedures too in the future.
>>>> I have committed the changes on GitHub :)
>>>>
>>>> On Mon, May 23, 2016 at 4:21 PM, Vicențiu Ciorbaru <cvicentiu@xxxxxxxxx
>>>> > wrote:
>>>>
>>>>> Hi Varun,
>>>>>
>>>>> Getting the parser to accept the syntax is a good first step. Writing
>>>>> tests is the correct way to go also.
>>>>>
>>>>> Now we need to have a way to pass this extra information to the part
>>>>> of the code that stores / executes this procedure. When we encounter this
>>>>> AGGREGATE_SYM syntax we have to record it somewhere. We generally use the
>>>>> LEX structure for this. See if there is any flag member within it that you
>>>>> can use for this purpose. If you can't find any, you can potentially create
>>>>> one yourself.
>>>>>
>>>>> Now, it would be a good time to try and familiarize yourself with how
>>>>> we get from having a regular parsed function to storing it and afterwards
>>>>> executing it. This is the main logic that we have to deal with. I'm not
>>>>> going to suggest you any specific thing to do right now as there are
>>>>> multiple ways to do this. Try and come up with a simple plan on how to
>>>>> extend this functionality for our use case. You don't have to code it all,
>>>>> just yet :). We'll improve (or perhaps change it) afterwards. It doesn't
>>>>> have to be perfect the first time, but this way you'll get a try at
>>>>> designing an implementation idea.
>>>>>
>>>>> Great job so far!
>>>>> Vicentiu
>>>>>
>>>>> On Mon, 23 May 2016 at 09:04 Varun Gupta <varungupta1803@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> As in my previous mail I have added the FETCH statement to the parser
>>>>>> and have tested it, when the syntax is correct . Now I am writing test that
>>>>>> would also give an error for incorrect syntax. Also I would like how to
>>>>>> proceed further :).
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~maria-developers
>>>>>> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~maria-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>
>>>
>