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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@gmail.com> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp