Tarantool development patches archive
 help / color / mirror / Atom feed
From: "n.pettik" <korablev@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH 3/5] sql: use 'varbinary' as a name of type instead of 'blob'
Date: Mon, 29 Jul 2019 02:56:21 +0300	[thread overview]
Message-ID: <FDC290D9-ED89-4CA3-8FEC-8AA2BC17ABD8@tarantool.org> (raw)
In-Reply-To: <2e655514-0fec-8baf-20a8-d49e5586b047@tarantool.org>



> On 26 Jul 2019, at 01:03, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> wrote:
> 
> On 24/07/2019 13:42, Nikita Pettik wrote:
>> We are going to introduce new column type 'VARBINARY', which allows to
>> store values with MP_BIN msgpack format. On the other hand, now it is also
>> possible to meet this type: all literals in form of x'...' are
>> supposed to be inserted into SCALAR column type exactly with MP_BIN
>> encoding. Prior to this moment type of such values (encoded as MP_BIN)
>> was called 'blob'. Thus, let's fix all visible to user messages using
>> 'varbinary' name of type instead of 'blob'.
>> ---
>> src/box/lua/lua_sql.c          |  2 +-
>> src/box/sql/func.c             |  4 ++--
>> src/box/sql/vdbe.c             |  4 ++--
>> src/box/sql/vdbeapi.c          |  4 ++--
>> test/sql-tap/cast.test.lua     |  4 ++--
>> test/sql-tap/func.test.lua     |  2 +-
>> test/sql-tap/lua_sql.test.lua  |  4 ++--
>> test/sql-tap/position.test.lua | 16 ++++++++--------
>> test/sql/types.result          | 24 ++++++++++++------------
>> 9 files changed, 32 insertions(+), 32 deletions(-)
> 
> More mentionings of blob in messages visible to user.
> 
> func.c   :540, :1185, :1254, :1753
> vdbeapi.c:283, :382,  :1061
> vdbemem.c:996, :1022
> vdbeaux.c:1192

All these usages are in form of:
"string or blob is too big”

I think that blob is a good name for entity of varbinary
type. Another possible names are “binary sequence”,
“binary data” or “binary string”. The latter variant is used
 in the ANSI specification. Now I’ve changed to “binary string”,
but if you can suggest better name, let’s discuss it.

Diff:

diff --git a/src/box/sql/func.c b/src/box/sql/func.c
index 4ec591eee..1a5671187 100644
--- a/src/box/sql/func.c
+++ b/src/box/sql/func.c
@@ -1182,7 +1182,8 @@ zeroblobFunc(sql_context * context, int argc, sql_value ** argv)
        if (n < 0)
                n = 0;
        if (sql_result_zeroblob64(context, n) != 0) {
-               diag_set(ClientError, ER_SQL_EXECUTE, "string or blob too big");
+               diag_set(ClientError, ER_SQL_EXECUTE, "string or binary string"\
+                        "is too big");
                context->is_aborted = true;
        }
 }
@@ -1251,7 +1252,7 @@ replaceFunc(sql_context * context, int argc, sql_value ** argv)
                        testcase(nOut - 2 == db->aLimit[SQL_LIMIT_LENGTH]);
                        if (nOut - 1 > db->aLimit[SQL_LIMIT_LENGTH]) {
                                diag_set(ClientError, ER_SQL_EXECUTE, "string "\
-                                        "or blob too big");
+                                        "or binary string is too big");
                                context->is_aborted = true;
                                sql_free(zOut);
                                return;
@@ -1750,8 +1751,8 @@ groupConcatFinalize(sql_context * context)
        pAccum = sql_aggregate_context(context, 0);
        if (pAccum) {
                if (pAccum->accError == STRACCUM_TOOBIG) {
-                       diag_set(ClientError, ER_SQL_EXECUTE, "string or blob "\
-                                "too big");
+                       diag_set(ClientError, ER_SQL_EXECUTE, "string or binary"\
+                                "string is too big");
                        context->is_aborted = true;
                } else if (pAccum->accError == STRACCUM_NOMEM) {
                        context->is_aborted = true;
diff --git a/src/box/sql/vdbeapi.c b/src/box/sql/vdbeapi.c
index 3bda7d145..217a9f22d 100644
--- a/src/box/sql/vdbeapi.c
+++ b/src/box/sql/vdbeapi.c
@@ -280,8 +280,8 @@ invokeValueDestructor(const void *p,        /* Value to destroy */
                xDel((void *)p);
        }
        if (pCtx) {
-               diag_set(ClientError, ER_SQL_EXECUTE, "string or blob is too "\
-                        "big");
+               diag_set(ClientError, ER_SQL_EXECUTE, "string or binary string"\
+                        "is too big");
                pCtx->is_aborted = true;
        }
        return -1;
@@ -379,8 +379,8 @@ sql_result_zeroblob64(sql_context * pCtx, u64 n)
 {
        Mem *pOut = pCtx->pOut;
        if (n > (u64) pOut->db->aLimit[SQL_LIMIT_LENGTH]) {
-               diag_set(ClientError, ER_SQL_EXECUTE, "string or blob is too "\
-                        "big");
+               diag_set(ClientError, ER_SQL_EXECUTE, "string or binary string"\
+                        "is too big");
                return -1;
        }
        sqlVdbeMemSetZeroBlob(pCtx->pOut, (int)n);
@@ -1058,8 +1058,8 @@ sql_bind_zeroblob64(sql_stmt * pStmt, int i, sql_uint64 n)
 {
        Vdbe *p = (Vdbe *) pStmt;
        if (n > (u64) p->db->aLimit[SQL_LIMIT_LENGTH]) {
-               diag_set(ClientError, ER_SQL_EXECUTE, "string or blob is too "\
-                        "big");
+               diag_set(ClientError, ER_SQL_EXECUTE, "string or binary string"\
+                        "is too big");
                return -1;
        }
        assert((n & 0x7FFFFFFF) == n);
diff --git a/src/box/sql/vdbeaux.c b/src/box/sql/vdbeaux.c
index baeeb4624..de50860bb 100644
--- a/src/box/sql/vdbeaux.c
+++ b/src/box/sql/vdbeaux.c
@@ -1189,7 +1189,7 @@ displayP4(Op * pOp, char *zTemp, int nTemp)
                                zP4 = "NULL";
                        } else {
                                assert(pMem->flags & MEM_Blob);
-                               zP4 = "(blob)";
+                               zP4 = "(binary string)";
                        }
                        break;
                }
diff --git a/src/box/sql/vdbemem.c b/src/box/sql/vdbemem.c
index d85148bc3..274f80a18 100644
--- a/src/box/sql/vdbemem.c
+++ b/src/box/sql/vdbemem.c
@@ -993,8 +993,8 @@ sqlVdbeMemSetStr(Mem * pMem,        /* Memory cell to set to string value */
                        nAlloc += 1; //SQL_UTF8
                }
                if (nByte > iLimit) {
-                       diag_set(ClientError, ER_SQL_EXECUTE, "string or blob "\
-                                "is too big");
+                       diag_set(ClientError, ER_SQL_EXECUTE, "string or binary"\
+                                "string is too big");
                        return -1;
                }
                testcase(nAlloc == 0);
@@ -1019,8 +1019,8 @@ sqlVdbeMemSetStr(Mem * pMem,      /* Memory cell to set to string value */
        pMem->flags = flags;
 
        if (nByte > iLimit) {
-               diag_set(ClientError, ER_SQL_EXECUTE, "string or blob is too "\
-                        "big");
+               diag_set(ClientError, ER_SQL_EXECUTE, "string or binary string"\
+                        "is too big");
                return -1;
        }

  parent reply	other threads:[~2019-07-28 23:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24 11:42 [tarantool-patches] [PATCH 0/5] Introduce VARBINARY in SQL Nikita Pettik
2019-07-24 11:42 ` [tarantool-patches] [PATCH 1/5] sql: always erase numeric flag after stringifying Nikita Pettik
2019-07-24 11:42 ` [tarantool-patches] [PATCH 2/5] sql: fix resulting type calculation for CASE-WHEN stmt Nikita Pettik
2019-07-25 22:12   ` [tarantool-patches] " Vladislav Shpilevoy
     [not found]   ` <a061e845-eeb1-00d1-9141-3b9bb87768f5@tarantool.org>
2019-07-28 23:56     ` n.pettik
2019-07-24 11:42 ` [tarantool-patches] [PATCH 3/5] sql: use 'varbinary' as a name of type instead of 'blob' Nikita Pettik
2019-07-25 22:11   ` [tarantool-patches] " Vladislav Shpilevoy
     [not found]   ` <2e655514-0fec-8baf-20a8-d49e5586b047@tarantool.org>
2019-07-28 23:56     ` n.pettik [this message]
2019-07-29 21:03       ` Vladislav Shpilevoy
2019-07-30 13:43         ` n.pettik
2019-07-24 11:42 ` [tarantool-patches] [PATCH 4/5] sql: make built-ins raise errors for varbin args Nikita Pettik
2019-07-25 22:11   ` [tarantool-patches] " Vladislav Shpilevoy
     [not found]   ` <05d15035-2552-1f05-b7ce-facfbbc3a520@tarantool.org>
2019-07-28 23:59     ` n.pettik
2019-07-24 11:42 ` [tarantool-patches] [PATCH 5/5] sql: introduce VARBINARY column type Nikita Pettik
2019-07-25 22:12   ` [tarantool-patches] " Vladislav Shpilevoy
     [not found]   ` <49a188eb-dafe-44e7-a0fd-e9244b68e721@tarantool.org>
2019-07-29  0:03     ` n.pettik
2019-07-29 20:55       ` Vladislav Shpilevoy
2019-07-30 13:44         ` n.pettik
2019-07-30 19:41           ` Vladislav Shpilevoy
2019-07-30 19:52             ` Vladislav Shpilevoy
2019-07-31 14:51               ` n.pettik
2019-08-01  8:42 ` [tarantool-patches] Re: [PATCH 0/5] Introduce VARBINARY in SQL 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=FDC290D9-ED89-4CA3-8FEC-8AA2BC17ABD8@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='[tarantool-patches] Re: [PATCH 3/5] sql: use '\''varbinary'\'' as a name of type instead of '\''blob'\''' \
    /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