maria-developers team mailing list archive

[Sanja <sanja.byelkin@xxxxxxxxx>]

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
>>>>>
>>>>
>>>
>>