{"push_id":3064549071,"size":43,"distinct_size":9,"ref":"refs/heads/kshch/gh-1012-json-indexes","head":"c9057652801756eb645f03002d7113529f0646ea","before":"3b4e4c8282b955516ed1f64aabd0891ad9e637a8","commits":[{"sha":"b2ddd18a1d8aff6304a564724380a02d65358b14","author":{"name":"Vladislav Shpilevoy","email":"a8b4141288f9d73d27e0ff2de4f33e33777360c5@tarantool.org"},"message":"box: allow cdata uint as box.session.push sync\n\nCloses #3790","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/b2ddd18a1d8aff6304a564724380a02d65358b14"},{"sha":"159df2c3a307c56d0c73d339b222990a19527f46","author":{"name":"Sergei Voronezhskii","email":"7c4f3d15d8fe4dc91f8b579699c38e75ade22d66@tarantool.org"},"message":"travis: add Ubuntu 18.10 Cosmic Cuttlefish\n\nCloses: #3761","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/159df2c3a307c56d0c73d339b222990a19527f46"},{"sha":"77fa1736dbb97d4f6e84b4ad7ed422da035094d0","author":{"name":"Vladislav Shpilevoy","email":"a8b4141288f9d73d27e0ff2de4f33e33777360c5@tarantool.org"},"message":"box: factor fiber_gc out of txn_commit\n\nNow txn_commit is judge, jury and executioner. It both\ncommits and rollbacks data, and collects it calling fiber_gc,\nwhich destroys the region.\n\nBut SQL wants to use some transactional data after commit. It is\nautogenerated identifiers - a list of sequence values generated\nfor autoincrement columns and explicit sequence:next() calls.\n\nIt is possible to store the list on malloced mem inside Vdbe, but\nit complicates deallocation. Much more convenient to store all\ntransactional data on the transaction memory region, so it would\nbe freed together with fiber_gc.\n\nAfter this patch applied, Vdbe takes care of txn memory\ndeallocation in a finalizer routine. Between commit and\nfinalization transactional data can be serialized wherever.\n\nNeeded for #2618","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/77fa1736dbb97d4f6e84b4ad7ed422da035094d0"},{"sha":"ef67de414f5dc21a4b1c01d5a068e3a7604a6f17","author":{"name":"Mergen Imeev","email":"3704c021c2a271260e9bf466142287ca9d5f2fd6@gmail.com"},"message":"sql: return all generated ids via IPROTO\n\nAccording to documentation some JDBC functions have an ability to\nreturn all ids that were generated in executed INSERT statement.\nThis patch gives a way to implement such functionality. After\nthis patch all ids autogenerated during VDBE execution will be\nsaved and returned through IPROTO.\n\nCloses #2618","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/ef67de414f5dc21a4b1c01d5a068e3a7604a6f17"},{"sha":"50e014e596fdd9cee587a464ed045918c3d2ceec","author":{"name":"Vladislav Shpilevoy","email":"a8b4141288f9d73d27e0ff2de4f33e33777360c5@tarantool.org"},"message":"sql: remove psql_txn from Vdbe\n\nIt makes no sense to store it here. SQL transaction\nspecific things shall be taken from global txn object,\nas any transaction specific things.\n\nFollow up #2618","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/50e014e596fdd9cee587a464ed045918c3d2ceec"},{"sha":"cfa7da04a052e04d4b267790e9fe368d60837dc8","author":{"name":"Mergen Imeev","email":"3704c021c2a271260e9bf466142287ca9d5f2fd6@gmail.com"},"message":"sql: refresh result-file of sql/iproto.test.lua\n\nTest sql/iproto.test.lua fails due to its result-file being a bit\noutdated.\n\nFollow up #2618","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/cfa7da04a052e04d4b267790e9fe368d60837dc8"},{"sha":"031aea109f8831ea2dca0920c9241579373db9ad","author":{"name":"Serge Petrenko","email":"4bf77e14b453588e946bed7791160bc794dc99f3@tarantool.org"},"message":"box: ensure fiber processing box_cfg doesn't process messages from iproto\n\nIn box_cfg() we have a call to gc_set_wal_watcher(), which creates pipes\nbetween 'wal' and 'tx' under the hood using cbus_pair().\nWhile pipes are being created, the fiber calling gc_set_wal_watcher()\nwill process all the messages coming to 'tx' thread from iproto. This is\nwrong, since we have a separate fiber pool to handle iproto messages,\nand background fibers shouldn't participate in these messages\nprocessing. For example, this causes occasional credential corruption in\nthe fiber executing box_cfg().\n\nSince tx fiber pool is already created at the time gc_set_wal_watcher()\nis called, we may forbid message processing for the fiber which calls\nthe function, one of the tx fiber pool fibers will wake us up when the\npipes are created.\n\nCloses #3779","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/031aea109f8831ea2dca0920c9241579373db9ad"},{"sha":"14ba68f93bb2008efd78fd544ac9617b2cd610fa","author":{"name":"Georgy Kirichenko","email":"7045372e045cf866a5eaf482c2da03ddffdf975f@tarantool.org"},"message":"Return valid lua error for func creation error\n\nReturn valid lua error if something fails during sql function creation.\n\nCloses #3724","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/14ba68f93bb2008efd78fd544ac9617b2cd610fa"},{"sha":"77ba27c639c1f6793187c7185d5f540543ba002d","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"space: add method to fetch next rowid\n\nEphemeral space are extensively used in SQL to store intermediate\nresults of query processing. To keep things simple, they feature only\none unique index (primary) which covers all fields. However, ephemeral\nspace can be used to store non-unique entries. In this case, one\nadditional field added to the end if stored data:\n\n[field1, ... fieldn, rowid]\n\nNote that it can't be added to the beginning of tuple since data in\nephemeral space may be kept as sorted. Previously, to generate proper\nrowid index_max() was used. However, it is obviously wrong way to do it.\nHence, lets add simple integer counter to memtx space (ephemeral spaces\nare valid only for memtx engine) and introduce method in vtab to fetch\nnext rowid value.\n\nNeeded for #3297","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/77ba27c639c1f6793187c7185d5f540543ba002d"},{"sha":"f9bbf8cc1f2daa0ec7844567351f9aea785e4a6c","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: use vtab::rowid_next() instead of index_max()\n\nAfter introducing separate method in space's vtab to fetch next rowid\nvalue, lets use it in SQL internals. This allows us to fix incorrect\nresults of queries involving storing equal tuples in ephemeral spaces.\n\nCloses #3297","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/f9bbf8cc1f2daa0ec7844567351f9aea785e4a6c"},{"sha":"19b64e013e8e7751e04f1916c80a89980ba361cb","author":{"name":"N.Tatunov","email":"ca815756155488523774216826e6d336d99c1619@gmail.com"},"message":"sql: LIKE & GLOB pattern comparison issue\n\nCurrently function that compares pattern and string for GLOB & LIKE\noperators doesn't work properly. It uses ICU reading function which\nwas assumed having other return codes and the implementation for the\ncomparison ending isn't paying attention to some special cases, hence\nin those cases it works improperly.\n\nWith the patch applied an error will be returned in case there's an\ninvalid UTF-8 symbol in pattern & pattern containing only valid UTF-8\nsymbols will not be matched with the string that contains invalid\nsymbol.\n\nСloses #3251\nСloses #3334\nPart of #3572","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/19b64e013e8e7751e04f1916c80a89980ba361cb"},{"sha":"5e3c0a1b017d65f2c1745c28af9a3789b196cac3","author":{"name":"N.Tatunov","email":"fd44afaad5a6e8d3b444531b6b745586623982c5@tarantool.org"},"message":"sql: remove GLOB from Tarantool\n\nGLOB is a legacy extension for LIKE from SQLite. As we want our SQL to\nbe close to ANSI SQL & LIKE to depend on collations, we do not want to\nsupport it. This patch totally removes it from Tarantool along with any\nmentions of it.\n\nPart of #3589\nPart of #3572","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/5e3c0a1b017d65f2c1745c28af9a3789b196cac3"},{"sha":"7412ecd6c4dc955a1c6c200cf2cfa4464724ef1b","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: don't increment row count on FK creation within CREATE or DROP table\n\nWe have agreement that each successful DDL operation returns 1 (one) as\na row count (via IProto protocol or changes() SQL function), despite\nthe number of other created objects (e.g. indexes, sequences, FK\nconstraints etc).\n\nNeeded for #2181","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/7412ecd6c4dc955a1c6c200cf2cfa4464724ef1b"},{"sha":"12f20fc7077760c6fa2a012b4fc51c6acf4874d1","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: account REPLACE as two row changes\n\nIn our SQL implementation REPLACE acts as DELETE + INSERT, so we should\naccount it as two row changes.\n\nNeeded for #2181","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/12f20fc7077760c6fa2a012b4fc51c6acf4874d1"},{"sha":"6857f50bfb47bcdad0afbf2ca5bd6fa7b3603751","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: remove total_changes() function\n\nPart of #2181","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/6857f50bfb47bcdad0afbf2ca5bd6fa7b3603751"},{"sha":"2852b4af8b123402bbee3a55cb325027ce3a872d","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: rename changes() to row_count()\n\nchanges() is legacy function which came from SQLite. However, its name\nis not perfect since it's \"number of rows affected\", not\"number of rows\nchanged\". Moreover, to make it real row count, we are nullifying counter\nrepresenting it in case operation is not accounted for DML or DDL.\nFor example, before this patch behavior was like:\n\nINSERT INTO t VALUES (1), (2), (3);\nSTART TRANSACTION;\nSELECT changes();\n---\n- - [3]\n...\n\nAs one can see, row counter remained unchanged from last INSERT\noperation. However, now START TRANSACTION set it to 0 and as a\nconsequence row_count() also returns 0.\n\nCloses #2181","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/2852b4af8b123402bbee3a55cb325027ce3a872d"},{"sha":"3eb796a122d2e18d59bd20c11405fa3c1852f1a2","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: do not add explicit <COLLATE \"BINARY\"> clause\n\nWe don't need to add explicit COLLATE \"BINARY\" clause since binary\ncollation is anyway default. On the other hand, it may confuse\ndue to ambiugty when comparing two terms.\n\nNeeded for #3185","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/3eb796a122d2e18d59bd20c11405fa3c1852f1a2"},{"sha":"3dc03f135cccf6bd912358b31af57c43e132561c","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: don't uppercase name of binary collation\n\nSince now we don't have real binary collation, it was allowed to use its\nname in different cases. For instance: BiNaRY, \"bInArY\", \"BINARY\" etc.\nAll these names were valid and accounted for binary collation.\nHowever, we are going to introduce real entry in _collation space to\nrepresent binary collation. Thus, for now we allow using only standard\n\"binary\" name.\n\nNeeded for #3185","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/3dc03f135cccf6bd912358b31af57c43e132561c"},{"sha":"a953051e4c2162ba789ab27c76cf35749d460468","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"Introduce \"none\" and \"binary\" collations\n\nThis patch introduces two new collation sequences: \"none\" and \"binary\".\nDespite the fact that they use the same comparing algorithm (simple\nbyte-by-byte comparison), they don't mean the same. \"binary\" collation\nget to the format if user explicitly points it: either specifies this\ncollation in space format manually or adds <COLLATE BINARY> clause to\ncolumn definition within CREATE TABLE statement. \"none\" collation is\nused when user doesn't specify any collation at all. \"none\" collation always\ncomes with id == 0 and it can't be changed (since its id vastly used\nunder the hood as an indicator of absence of collation).\nDifference between these collations is vital for ANSI SQL: mixing\n\"binary\" with other collations is prohibited, meanwhile \"none\" collation\ncan be used alongside with others.\nIn this respect current patch extends list of available collations: now\nnot only ICU collations are allowed, but also BINARY.\n\nNote, that in SQL some queries have changed their query plan. That\noccurred due to the fact that our parser allows using <COLLATE> clause\nwith numeric fields:\n\nCREATE TABLE (id INT PRIMARY KEY);\nSELECT id COLLATE \"binary\" ...\n\nIn the example collation of LHS (id column) is NULL, but collation of\nRHS is \"binary\". Before this patch both collations were NULL. Hence,\nusage of certain indexes may not be allowed by query planner.\nOn the other hand, this feature is obviously broken, so that doesn't\nseem to be big deal.\n\nNeeded for #3185","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/a953051e4c2162ba789ab27c76cf35749d460468"},{"sha":"8a09adb469b6c243cb3b9118d904880b65c565ce","author":{"name":"Nikita Pettik","email":"f5426693cd7bcafd8a529d1adfff964ab6d38d38@tarantool.org"},"message":"sql: change collation compatibility rules\n\nBefore this patch our SQL implementation relied on strange rules\nwhen comparing strings with different collations:\n\n- if either operand has an explicit collating function assignment using\n  the postfix COLLATE operator, then the explicit collating function is\n  used for comparison, with precedence to the collating function of the\n  left operand;\n\n- if either operand is a column, then the collating function of that\n  column is used with precedence to the left operand.\n\nThe main concern in this implementation is that collation of the left\noperand is forced over right one (even if both operands come with\nexplicit COLLATE clause). This contradicts ANSI SQL and seems to be\nquite misleading, since if user simple swap LHS and RHS - result of\nquery may change.\n\nLets introduce restrictions concerning collations compatibilities.\nCollations of LHS and RHS are compatible (i.e. no \"Illegal mix of\ncollations\" is thrown) if:\n\n- one of collations is mentioned alongside with explicit COLLATE clause,\n  which forces this collation over another one. It is allowed to have\n  the same forced collations;\n\n- both collations are derived from table columns and they are the same;\n\n- one collation is derived from table column and another one is not\n  specified (i.e. COLL_NONE).\n\nThe compound SELECT operators UNION, INTERSECT and EXCEPT perform implicit\ncomparisons between values. Hence, all new rules stated above are\napplied to parts of compound SELECT. Otherwise, an error is raised.\nIn other words, before current patch queries like below were allowed:\n\nSELECT 'abc' COLLATE binary UNION SELECT 'ABC' COLLATE \"unicode_ci\";\n---\n- - ['ABC']\n  - ['abc']\n...\n\nIf we swap collations, we will get another result:\n\nSELECT 'ABC' COLLATE \"unicode_ci\" UNION SELECT 'abc' COLLATE BINARY\n---\n- - ['abc']\n...\n\nNow such queries are illegal.\n\nCloses #3185","distinct":false,"url":"https://api.github.com/repos/tarantool/tarantool/commits/8a09adb469b6c243cb3b9118d904880b65c565ce"}]}
{"actor":{"display_login":"kshcherbatov"}}