Tarantool development patches archive
 help / color / mirror / Atom feed
From: "n.pettik" <korablev@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
	Kirill Shcherbatov <kshcherbatov@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH v2 1/1] Removed Expr pointer from SQL Column structure.
Date: Thu, 19 Apr 2018 15:58:53 +0300	[thread overview]
Message-ID: <1F5EB31E-147B-4373-8EFA-B1E158792997@tarantool.org> (raw)
In-Reply-To: <5eaf0628-8f05-eb95-1a4c-76b69e66cc00@tarantool.org>

Hello. Several minor comments. Overall, seems OK to me.

> +/**
> + * Create and initialize a new SQL Table object.
> + * @param pParse SQL Parser object.
> + * @param zName Table to create name.
> + * @retval NULL on memory allocation error, Parser state is
> + *         changed.
> + * @retval not NULL on success.
> + */
> +static Table *
> +sql_table_new(Parse *pParse, char *zName)
> +{

I would use Tarantool codestyle as well for args and vars
inside function. It is not mandatory, but would look better.

> +/**
> + * Get field by id. Allocate memory if needed.
> + * @param pParse SQL Parser object.
> + * @param pTable SQL Table object.
> + * @param id column identifier.
> + * @retval not NULL on success.
> + * @retval NULL on out of memory.
> + */
> +static struct field_def *
> +sql_field_retrieve(Parse *pParse, Table *pTable, uint32_t id)
> +{

The same is here: you can use Tarantool codestyle for vars/args.
Also, I strongly recommend you to add some explanation
comments, in particular concerning allocating strategy.
It doesn’t seem to be obvious (at least for independent reviewer).

> +	sqlite3 *db = pParse->db;
> +	struct field_def *field;
> +	assert(pTable->def);

Use explicit != NULL check.

> +	assert(pTable->def->exact_field_count >= (uint32_t)pTable->nCol);
> +	assert(id < (uint32_t)db->aLimit[SQLITE_LIMIT_COLUMN]);

I have grepped through code, and it seems that this 'limit'
is valid only under SQLITE_MAX_COLUMN macros.
What about removing this macros (i.e. we will make this feature be always enabled),
or surrounding your code with #ifdef directives?

> +
> +	if (id >= pTable->def->exact_field_count) {
> +		uint32_t nCol = pTable->def->exact_field_count;
> +		nCol = (nCol > 0) ? 2 * nCol : 1;
> +		field = sqlite3DbRealloc(db, pTable->def->fields,
> +					 nCol * sizeof(pTable->def->fields[0]));

What about using simple malloc/realloc? It would allow you
to get rid of pParse argument.

> diff --git a/src/box/sql/insert.c b/src/box/sql/insert.c
> index b24d55b07..067f50a0a 100644
> --- a/src/box/sql/insert.c
> +++ b/src/box/sql/insert.c
> @@ -1801,14 +1801,21 @@ xferOptimization(Parse * pParse,	/* Parser context */
> 		}
> 		/* Default values for second and subsequent columns need to match. */
> 		if (i > 0) {
> -			assert(pDestCol->pDflt == 0
> -			       || pDestCol->pDflt->op == TK_SPAN);
> -			assert(pSrcCol->pDflt == 0
> -			       || pSrcCol->pDflt->op == TK_SPAN);
> -			if ((pDestCol->pDflt == 0) != (pSrcCol->pDflt == 0)
> -			    || (pDestCol->pDflt
> -				&& strcmp(pDestCol->pDflt->u.zToken,
> -					  pSrcCol->pDflt->u.zToken) != 0)
> +			uint32_t src_space_id =
> +				SQLITE_PAGENO_TO_SPACEID(pSrc->tnum);
> +			struct space *src_space =
> +				space_cache_find(src_space_id);

space_cache_find() can return NULL pointer. I would check it on nullability somehow.

> +			uint32_t dest_space_id =
> +				SQLITE_PAGENO_TO_SPACEID(pDest->tnum);
> +			struct space *dest_space =
> +				space_cache_find(dest_space_id);
> +			char *src_expr_str =
> +				src_space->def->fields[i].default_value;
> +			char *dest_expr_str =
> +				dest_space->def->fields[i].default_value;
> +			if ((dest_expr_str == NULL) != (src_expr_str == NULL)
> +			    || (dest_expr_str

Codestyle nitpicking: put binary operator on previous line:
 … A &&
B 

  reply	other threads:[~2018-04-19 12:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 16:35 [tarantool-patches] " Kirill Shcherbatov
2018-04-16 19:23 ` [tarantool-patches] " Vladislav Shpilevoy
2018-04-17 11:02   ` Kirill Shcherbatov
2018-04-17 18:29     ` Vladislav Shpilevoy
2018-04-17 18:30       ` Vladislav Shpilevoy
2018-04-18  7:31         ` Kirill Shcherbatov
2018-04-18  9:47           ` Vladislav Shpilevoy
2018-04-19 12:58             ` n.pettik [this message]
2018-04-19 14:07               ` Kirill Shcherbatov
2018-04-19 15:05                 ` n.pettik
2018-04-21  8:51                   ` Kirill Yukhin

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=1F5EB31E-147B-4373-8EFA-B1E158792997@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=kshcherbatov@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='[tarantool-patches] Re: [PATCH v2 1/1] Removed Expr pointer from SQL Column structure.' \
    /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