From: Kirill Shcherbatov <kshcherbatov@tarantool.org> To: tarantool-patches@freelists.org, "n.pettik" <korablev@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v2 7/8] sql: get rid of FuncDef function hash Date: Fri, 16 Aug 2019 15:57:13 +0300 [thread overview] Message-ID: <00293576-fea9-151f-11cf-85afe76b065e@tarantool.org> (raw) In-Reply-To: <F4856BA8-8F2B-4577-9918-516A8E7C5BBC@tarantool.org> >> It has a sql-specific method :call and :finalize typica while > > Nit: typic? Please, consider using spell-checker. >> Following tests using sql_create_function are broken now. >> They would be fixed in the following commit: > > Nit: are going to be fixed in the next commit. Fixed. >> + /** A call method for a function. */ > > Add explanation why we don’t use basic (i.e. call > method of base class) “call” method. Furthermore, > built-ins are called bypassing func_access_check() > function. This should be either documented or fixed. /** * A VDBE-memory-compatible call method for a function. * SQL Builting functions doesn't use base class call * method to gain the best possible performance for SQL * requests. As builtin functions are predefined and * non of them modifie schema, access checks are * redundant, functions have the same execution * privileges as SQL. */ void (*call)(sql_context *ctx, int argc, sql_value **argv); >> + /** Finalize method (only for aggregate function). */ >> + void (*finalize)(sql_context *ctx); > > We hold aggregate attribute in func_def; I guess > lua/C aggregate are not going to be implemented > soon (or someday at all); so, considering these > points, why not to move this method to the base vtab? Verbally discussed. It is vdbe-memory-oriented API, so it shouldn't be in abstract function's vtab. >> +/** >> + * A SQL method to find a function in a hash by it's name and > > Nit: it’s (it is) -> its. >> + * Returns not NULL function pointer when a valid and exported >> + * to SQL engine function was found and NULL otherwise. > > Nit: was found -> is found. Fixed. >> +static inline bool >> +sql_func_flag_test(struct func *func, uint16_t flag) > > At least I would rename it to sql_func_test_flag() or > sql_builtin_flag_is_set() or smth like that. Verbally discussed, I believe that it is the most representative name for this helper. >> +/** >> + * Memory cell pMem contains the context of an aggregate function. > > Nit: pMem -> mem. Fixed. >> -static void >> +MAYBE_UNUSED static void > > Is this change really related to the patch? Same for > all other added MAYBE_UNUSED modifiers. I don't initialze analyze functions because the are currently unused, but I don't like to remove their implementation. >> assert(func != NULL); > > Instead of asserting func existence let’s raise an error: now > user can remove built-in function from hash - there’s no > protection to avoid such cases. Note that such opportunity > (removing built-ins from cache) has been introduced by moving > built-ins to the global func cache. In this case, assertion will fail > in debug mode and lead to unpredictable consequences in > release mode. Another option is to introduce mentioned protection, > i.e. disallow user to delete functions which are declared with > FUNC_LANGUAGE_SQL_BUILTIN flag. I've introduce remove protection in alter.cc >> + func->def->aggregate == FUNC_AGGREGATE_GROUP) { > > Why do we need check on aggregation type? Works also without it, thanks. >> + diag_set(ClientError, ER_CREATE_FUNCTION, def->name, >> + "body and is_sandboxed options are not compatible " >> + "with SQL language”); > > Why not move this check to func_def_new_from_tuple() ? Already there. >> + func->flags = sql_builtins[idx].flags; >> + func->user_data = sql_builtins[idx].user_data; >> + func->call = sql_builtins[idx].call; >> + func->finalize = sql_builtins[idx].finalize; >> + func->signature_mask = sql_builtins[idx].signature_mask; >> + func->base.vtab = &func_sql_builtin_vtab; >> + func->base.def = def; >> + > Why not memcpy? Because it is partial func def initialization. Can't just mecpy it. > Nit: double semicolon at the end of string. Fixed. > > Can aggregate function be non-builtin? Not for now, but I don't like to rely on it so I make all corresponding checks. > SQL_FUNC_SLOCHNG seems to be unused. > So, you can simply remove it. Removed in separate commit. >> + (*((struct func_sql_builtin *)pCtx->func)->call)(pCtx, pCtx->argc, >> + pCtx->argv); > > Nit: please, split it into two steps: type cast and function call. Done. > user_data is used only for min/max functions. Let’s consider removing it. Removed user_data at all. >> + assert(p != NULL && p->func != NULL && >> + p->func->def->language == FUNC_LANGUAGE_SQL_BUILTIN && >> + p->func->def->aggregate == FUNC_AGGREGATE_GROUP); > > Please, split this assert into three ones. IMHO it would > improve code readability. Done. >> - if (ALWAYS(pFunc && pFunc->xFinalize)) { >> + if (ALWAYS(func != NULL && > > Please, move assert inside if condition to a separate stmt(s): Done.
next prev parent reply other threads:[~2019-08-16 12:57 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-08 14:50 [tarantool-patches] [PATCH v2 0/8] sql: uniform SQL and Lua functions subsystem Kirill Shcherbatov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 1/8] sql: remove SQL_PreferBuiltin flag Kirill Shcherbatov 2019-08-09 16:07 ` [tarantool-patches] " n.pettik 2019-08-12 21:58 ` Konstantin Osipov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 2/8] sql: GREATEST, LEAST instead of MIN/MAX overload Kirill Shcherbatov 2019-08-09 17:37 ` [tarantool-patches] " n.pettik 2019-08-13 8:26 ` Kirill Shcherbatov 2019-08-12 21:59 ` Konstantin Osipov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 3/8] sql: wrap all trim functions in dispatcher Kirill Shcherbatov 2019-08-09 18:05 ` [tarantool-patches] " n.pettik 2019-08-13 8:28 ` Kirill Shcherbatov 2019-08-13 22:19 ` n.pettik 2019-08-12 22:00 ` Konstantin Osipov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 4/8] sql: get rid of SQL_FUNC_COUNT flag Kirill Shcherbatov 2019-08-12 22:01 ` [tarantool-patches] " Konstantin Osipov 2019-08-13 20:35 ` n.pettik 2019-08-14 7:25 ` Kirill Shcherbatov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 5/8] sql: introduce a signature_mask for functions Kirill Shcherbatov 2019-08-12 22:04 ` [tarantool-patches] " Konstantin Osipov 2019-08-13 8:32 ` Kirill Shcherbatov 2019-08-13 8:44 ` Konstantin Osipov 2019-08-13 20:38 ` n.pettik 2019-08-14 7:21 ` Kirill Shcherbatov 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 6/8] sql: rename OP_Function to OP_BuiltinFunction Kirill Shcherbatov 2019-08-12 22:04 ` [tarantool-patches] " Konstantin Osipov 2019-08-13 20:36 ` n.pettik 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 7/8] sql: get rid of FuncDef function hash Kirill Shcherbatov 2019-08-12 22:11 ` [tarantool-patches] " Konstantin Osipov 2019-08-13 7:29 ` Kirill Shcherbatov 2019-08-13 8:42 ` Konstantin Osipov 2019-08-13 9:45 ` Kirill Shcherbatov 2019-08-13 20:40 ` n.pettik 2019-08-16 12:57 ` Kirill Shcherbatov [this message] 2019-08-20 16:06 ` n.pettik 2019-08-08 14:50 ` [tarantool-patches] [PATCH v2 8/8] box: get rid of box.internal.sql_function_create Kirill Shcherbatov 2019-08-13 20:43 ` [tarantool-patches] " n.pettik 2019-08-16 12:57 ` Kirill Shcherbatov 2019-08-20 19:36 ` n.pettik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=00293576-fea9-151f-11cf-85afe76b065e@tarantool.org \ --to=kshcherbatov@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH v2 7/8] sql: get rid of FuncDef function hash' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox