[Maria-developers] GSoc weekly reports (Aggregate Functions)
![](https://secure.gravatar.com/avatar/b8654bb03e9f59f1ab0825f27d33e20d.jpg?s=120&d=mm&r=g)
Hi, Here is the week 2 report WEEK 2 dire = mariadb/server task - adding 'aggregate' field to the mysql.proc table. sub tasks 1) aggregate field ---> mysql.proc table 2)create function -----> aggregate and non-aggregate 3)show create function ----> aggregate and non-aggregate 4)drop function -----> aggregate and non-aggregate 5)alter function -----> aggregate and non-aggregate For the user he has two options for AGGREGATE (TRUE,FALSE); details 1) Added the field 'aggregate' to the proc table . Order should be maintained for the fields added. 2) Also included the column in the enumberation of db storage. 3) Added a new is_aggregate characteristic to the lex structure, which would help in identifying if a function is aggregate or not. 4) So after parsing the CREATE FUNCTION query ,adding to the table YES if function is aggregate else adding NO to the proc table. 5) SHOW FUNCTION query to load the aggregate field. We have the is_aggregate field to load the value in it. 6) DROP FUNCTION, required no changes to be made as the primary key does not have the aggregate field 7) ALTER FUNCTION , required adding the syntax for the AGGREGATE characteristic , so rules were added to add this additional alter characteristic. Then we had to update the routine row in the proc table for all the field that are going to be altered . So we store the new altered fields to the proc table for the stated fields.
![](https://secure.gravatar.com/avatar/39b623a1559cf9c69ac3d9d4fb44e7fe.jpg?s=120&d=mm&r=g)
Hi, Varun! On Jun 06, Varun Gupta wrote:
details
1) Added the field 'aggregate' to the proc table . Order should be maintained for the fields added.
Don't make it a YES/NO boolean. As MDEV-7773 says, we want to have window-aware aggregate functions some day. And while you're not doing it, you should not make this future extension unnecessary difficult :) See? It's kinda difficult to add a value to a YES/NO pair :) But, for example, you can have this 'aggregate' field be ENUM('NONE', 'GROUP') Then later we can easily add a new value to the enum: ENUM('NONE', 'GROUP', 'WINDOW') without breaking compatibilty. Hm, perhaps the field then should be called not 'aggregate', but 'aggregate_type'. Or may be not. And it does not have to be NONE/GROUP either - feel free to use other enum values, just make sure we can add a third value later for window-aware functions. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Sergei Golubchik
-
Varun Gupta