An error occurred fetching the project authors.
  1. 28 Sep, 2009 1 commit
    • Tatiana A. Nurnberg's avatar
      Bug#43746: YACC return wrong query string when parse 'load data infile' sql statement · 197182d7
      Tatiana A. Nurnberg authored
      "load data" statements were written to the binlog as a mix of the original statement
      and bits recreated from parse-info. This relied on implementation details and broke
      with IGNORE_SPACES and versioned comments.
      
      We now completely resynthesize the query for LOAD DATA for binlog (which among other
      things normalizes them somewhat with regard to case, spaces, etc.).
      We have already parsed the query properly, so we make use of that rather
      than mix-and-match string literals and parsed items.
      This should make us safe with regard to versioned comments, even those
      spanning multiple tokens. Also no longer affected by IGNORE_SPACES.
      197182d7
  2. 31 Jul, 2009 1 commit
    • Gleb Shchepa's avatar
      Bug# 30946: mysqldump silently ignores --default-character-set · e642140b
      Gleb Shchepa authored
                  when used with --tab
      
      1) New syntax: added CHARACTER SET clause to the
        SELECT ... INTO OUTFILE (to complement the same clause in
        LOAD DATA INFILE).
        mysqldump is updated to use this in --tab mode.
      
      2) ESCAPED BY/ENCLOSED BY field parameters are documented as
         accepting CHAR argument, however SELECT .. INTO OUTFILE
         silently ignored rests of multisymbol arguments.
         For the symmetrical behavior with LOAD DATA INFILE the
         server has been modified to fail with the same error:
      
           ERROR 42000: Field separator argument is not what is
                        expected; check the manual
      
      3) Current LOAD DATA INFILE recognizes field/line separators
         "as is" without converting from client charset to data
         file charset. So, it is supposed, that input file of
         LOAD DATA INFILE consists of data in one charset and
         separators in other charset. For the compatibility with
         that [buggy] behaviour SELECT INTO OUTFILE implementation
         has been saved "as is" too, but the new warning message
         has been added:
      
           Non-ASCII separator arguments are not fully supported
      
         This message warns on field/line separators that contain
         non-ASCII symbols.
      e642140b
  3. 17 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 30fccdaa
      Staale Smedseng authored
      with gcc 4.3.2
            
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                        
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      30fccdaa
  4. 10 Jun, 2009 1 commit
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · e6e1f4ac
      Staale Smedseng authored
      with gcc 4.3.2
      
      Compiling MySQL with gcc 4.3.2 and later produces a number of 
      warnings, many of which are new with the recent compiler
      versions.
                  
      This bug will be resolved in more than one patch to limit the
      size of changesets. This is the second patch, fixing more
      of the warnings.
      e6e1f4ac
  5. 30 May, 2009 1 commit
  6. 21 Feb, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#38174 secure-file-priv breaks LOAD DATA INFILE replication in statement mode · 4447ce61
      Alfranio Correia authored
                        
      If secure-file-priv was set on slave, it became unable to execute
      LOAD DATA INFILE statements sent from master using mixed or
      statement-based replication.
                        
      This patch fixes the issue by ignoring this security restriction
      and checking if the files are created and read by the slave in the
      --slave-load-tmpdir while executing the SQL Thread.
      4447ce61
  7. 10 Feb, 2009 1 commit
  8. 17 Sep, 2008 1 commit
  9. 28 Mar, 2008 1 commit
    • anozdrin/alik@quad.opbmk's avatar
      Fix for Bug#35469: server crash with LOAD DATA INFILE to a VIEW. · 2880d208
      anozdrin/alik@quad.opbmk authored
      The problem was that LOAD DATA code (sql_load.cc) didn't take into
      account that there may be items, representing references to other
      columns. This is a usual case in views. The crash happened because
      Item_direct_view_ref was casted to Item_user_var_as_out_param,
      which is not a base class.
      
      The fix is to
        1) Handle references properly;
        2) Ensure that an item is treated as a user variable only when
           it is a user variable indeed;
        3) Report an error if LOAD DATA is used to load data into
           non-updatable column.
      2880d208
  10. 21 Mar, 2008 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26461: Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) · ff0aac17
      gkodinov/kgeorge@macbook.gmz authored
      The bool data type was redefined to BOOL (4 bytes on windows).
      Removed the #define and fixed some of the warnings that were uncovered
      by this.
      Note that the fix also disables 2 warnings :
      4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
      4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
      
      These warnings will be handled in a separate bug, as they are performance related or bogus.
      
      Fixed to int the return type of functions that return more than 
      2 distinct values.
      ff0aac17
  11. 19 Feb, 2008 2 commits
  12. 30 Oct, 2007 1 commit
  13. 29 Oct, 2007 1 commit
    • aelkin/elkin@koti.dsl.inet.fi's avatar
      Bug #27571 asynchronousity in setting mysql_`query`::error and · 27436f0b
      aelkin/elkin@koti.dsl.inet.fi authored
                 Query_log_event::error_code
      
      A query can perform completely having the local var error of mysql_$query
      zero, where $query in insert, update, delete, load,
      and be  binlogged with error_code e.g KILLED_QUERY while there is no
      reason do to so.
      That can happen because Query_log_event consults thd->killed flag to
      evaluate error_code.
      
      Fixed with implementing a scheme suggested and partly implemented at
      time of bug@22725 work-on. error_status is cached immediatly after the
      control leaves the main rows-loop and that instance always corresponds
      to `error' the local of mysql_$query functions. The cached value
      is passed to Query_log_event constructor, not the default thd->killed
      which can be changed in between of the caching and the constructing.
      27436f0b
  14. 21 Aug, 2007 1 commit
  15. 30 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      (pushing for Andrei) · 9a0e6ec6
      gkodinov/kgeorge@magare.gmz authored
      Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
        
      Once had been set the flag might later got reset inside of a stored routine 
      execution stack.
      The reason was in that there was no check if a new statement started at time 
      of resetting.
      The artifact affects most of binlogable DML queries. Notice, that multi-update 
      is wrapped up within
        bug@27716 fix, multi-delete bug@29136.
        
      Fixed with saving parent's statement flag of whether the statement modified 
      non-transactional table, and unioning (merging) the value with that was gained 
      in mysql_execute_command.
        
      Resettling thd->no_trans_update members into thd->transaction.`member`;
      Asserting code;
      Effectively the following properties are held.
        
      1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
         reflects the fact if such a table got modified by the substatement.
         That also respects THD::really_abort_on_warnin() requirements.
      2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
         the union of the values of all invoked sub-statements.
         That fixes this bug#27417;
      
      Computing of thd->transaction.all.modified_non_trans_table is refined to base to 
      the stmt's value for all the case including insert .. select statement which 
      before the patch had an extra issue bug@28960.
      Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
      to temp_table select. 
        
      The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
      for bug@13270, bug@23333.
      9a0e6ec6
  16. 03 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29294. · dbe4fb94
      gshchepa/uchum@gleb.loc authored
      The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
      encoded the 'r' string to a 4 byte string of value x'725c7272'
      (sequence of 4 characters: r\rr).
      The LOAD DATA statement decoded this string to a 1 byte string of
      value x'0d' (ASCII Carriage Return character) instead of the original
      'r' character.
      The same error also happened with the FIELDS ENCLOSED BY clause
      followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.
      
      NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
      recognises 2-byte input sequences like \n, \t, \r and \Z in addition
      to documented 2-byte sequences: \0 and \N. This feature should be
      documented (here backspace character is a default ESCAPED BY character,
      in the real-life example it may be any ESCAPED BY character).
      
      NOTE 2, changed behaviour:
      Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
      clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
      encodes this special character itself by doubling it ('r' --> 'rr'),
      not by prepending it with an escape character.
      dbe4fb94
  17. 10 May, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      WL#3817: Simplify string / memory area types and make things more consistent (first part) · 088e2395
      monty@mysql.com/narttu.mysql.fi authored
      The following type conversions was done:
      
      - Changed byte to uchar
      - Changed gptr to uchar*
      - Change my_string to char *
      - Change my_size_t to size_t
      - Change size_s to size_t
      
      Removed declaration of byte, gptr, my_string, my_size_t and size_s. 
      
      Following function parameter changes was done:
      - All string functions in mysys/strings was changed to use size_t
        instead of uint for string lengths.
      - All read()/write() functions changed to use size_t (including vio).
      - All protocoll functions changed to use size_t instead of uint
      - Functions that used a pointer to a string length was changed to use size_t*
      - Changed malloc(), free() and related functions from using gptr to use void *
        as this requires fewer casts in the code and is more in line with how the
        standard functions work.
      - Added extra length argument to dirname_part() to return the length of the
        created string.
      - Changed (at least) following functions to take uchar* as argument:
        - db_dump()
        - my_net_write()
        - net_write_command()
        - net_store_data()
        - DBUG_DUMP()
        - decimal2bin() & bin2decimal()
      - Changed my_compress() and my_uncompress() to use size_t. Changed one
        argument to my_uncompress() from a pointer to a value as we only return
        one value (makes function easier to use).
      - Changed type of 'pack_data' argument to packfrm() to avoid casts.
      - Changed in readfrm() and writefrom(), ha_discover and handler::discover()
        the type for argument 'frmdata' to uchar** to avoid casts.
      - Changed most Field functions to use uchar* instead of char* (reduced a lot of
        casts).
      - Changed field->val_xxx(xxx, new_ptr) to take const pointers.
      
      Other changes:
      - Removed a lot of not needed casts
      - Added a few new cast required by other changes
      - Added some cast to my_multi_malloc() arguments for safety (as string lengths
        needs to be uint, not size_t).
      - Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
        explicitely as this conflict was often hided by casting the function to
        hash_get_key).
      - Changed some buffers to memory regions to uchar* to avoid casts.
      - Changed some string lengths from uint to size_t.
      - Changed field->ptr to be uchar* instead of char*. This allowed us to
        get rid of a lot of casts.
      - Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
      - Include zlib.h in some files as we needed declaration of crc32()
      - Changed MY_FILE_ERROR to be (size_t) -1.
      - Changed many variables to hold the result of my_read() / my_write() to be
        size_t. This was needed to properly detect errors (which are
        returned as (size_t) -1).
      - Removed some very old VMS code
      - Changed packfrm()/unpackfrm() to not be depending on uint size
        (portability fix)
      - Removed windows specific code to restore cursor position as this
        causes slowdown on windows and we should not mix read() and pread()
        calls anyway as this is not thread safe. Updated function comment to
        reflect this. Changed function that depended on original behavior of
        my_pwrite() to itself restore the cursor position (one such case).
      - Added some missing checking of return value of malloc().
      - Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
      - Changed type of table_def::m_size from my_size_t to ulong to reflect that
        m_size is the number of elements in the array, not a string/memory
        length.
      - Moved THD::max_row_length() to table.cc (as it's not depending on THD).
        Inlined max_row_length_blob() into this function.
      - More function comments
      - Fixed some compiler warnings when compiled without partitions.
      - Removed setting of LEX_STRING() arguments in declaration (portability fix).
      - Some trivial indentation/variable name changes.
      - Some trivial code simplifications:
        - Replaced some calls to alloc_root + memcpy to use
          strmake_root()/strdup_root().
        - Changed some calls from memdup() to strmake() (Safety fix)
        - Simpler loops in client-simple.c
      088e2395
  18. 08 May, 2007 3 commits
    • evgen@moonbone.local's avatar
      Bug#27670: LOAD DATA does not set CURRENT_TIMESTAMP default value for a · 98fa542a
      evgen@moonbone.local authored
      TIMESTAMP field when no value has been provided.
      
      The LOAD DATA sets the current time in the TIMESTAMP field with
      CURRENT_TIMESTAMP default value when the field is detected as a null.
      But when the LOAD DATA command loads data from a file that doesn't contain
      enough data for all fields then the rest of fields are simply set to null
      without any check. This leads to no value being inserted to such TIMESTAMP
      field.
      
      Now the read_sep_field() and the read_fixed_length() functions set current
      time to the TIMESTAMP field with CURRENT_TIMESTAMP default value in all cases
      when a NULL value is loaded to the field.
      98fa542a
    • cbell/Chuck@mysql_cab.'s avatar
      BUG#17233 : LOAD DATA INFILE: failure causes mysqld dbug_assert, binlog not flushed · e6718df3
      cbell/Chuck@mysql_cab. authored
      This patch corrects a bug involving a LOAD DATA INFILE operation on a 
      transactional table. It corrects a problem in the error handler by moving
      the transactional table check and autocommit_or_rollback operation to the 
      end of the error handler. 
      
      The problem was an assert was thrown after the operation completed. The 
      assert found a non-sunk event in the transaction cache. The events in the 
      transaction cache were added after commit_or_rollack and thereafter nothing 
      removed them.
      
      An additional test case was added to detect this
      condition.
      e6718df3
    • cbell/Chuck@mysql_cab.'s avatar
      BUG#17233 : LOAD DATA INFILE: failure causes mysqld dbug_assert, binlog not flushed · 41b8ddc8
      cbell/Chuck@mysql_cab. authored
      This patch corrects a bug involving a LOAD DATA INFILE operation on a 
      transactional table. It corrects a problem in the error handler moving
      the transactional table check and autocommit_or_rollback operation to the 
      end of the error handler. An additional test case was added to detect this
      condition.
      41b8ddc8
  19. 06 Apr, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27586: Wrong autoinc value assigned by LOAD DATA in the · 93c29c10
      evgen@moonbone.local authored
      NO_AUTO_VALUE_ON_ZERO mode.
      
      The table->auto_increment_field_not_null variable wasn't reset after
      reading a row which may lead to inserting a wrong value to the auto-increment
      field to the following row.
      
      The table->auto_increment_field_not_null variable is reset now right after a
      row is being written in the read_fixed_length() and the read_sep_field()
      functions.
      Removed wrong setting of the table->auto_increment_field_not_null variable in
      the read_sep_field() function.
      93c29c10
  20. 04 Apr, 2007 2 commits
    • mskold/marty@mysql.com/linux.site's avatar
      Merge from 5.0 · 6c8f5c58
      mskold/marty@mysql.com/linux.site authored
      6c8f5c58
    • mskold/marty@mysql.com/linux.site's avatar
      Bug #26242 UPDATE with subquery and triggers failing with cluster tables · 625a2629
      mskold/marty@mysql.com/linux.site authored
      In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced
      subject table didn't see the results of operation which caused invocation
      of those triggers. In other words AFTER trigger invoked as result of update
      (or deletion) of particular row saw version of this row before update (or
      deletion).
      
      The problem occured because NDB handler in those cases postponed actual
      update/delete operations to be able to perform them later as one batch.
      
      This fix solves the problem by disabling this optimization for particular
      operation if subject table has AFTER trigger for this operation defined.
      To achieve this we introduce two new flags for handler::extra() method:
      HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH.
      These are called if there exists AFTER DELETE/UPDATE triggers during a
      statement that potentially can generate calls to delete_row()/update_row().
      This includes multi_delete/multi_update statements as well as insert statements
      that do delete/update as part of an ON DUPLICATE statement.
      625a2629
  21. 30 Mar, 2007 1 commit
    • evgen@sunlight.local's avatar
      Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the · 7c42232d
      evgen@sunlight.local authored
      NO_AUTO_VALUE_ON_ZERO mode.
      
      In the NO_AUTO_VALUE_ON_ZERO mode the table->auto_increment_field_not_null
      variable is used to indicate that a non-NULL value was specified by the user
      for an auto_increment column. When an INSERT .. ON DUPLICATE updates the
      auto_increment field this variable is set to true and stays unchanged for the
      next insert operation. This makes the next inserted row sometimes wrongly have
      0 as the value of the auto_increment field.
      
      Now the fill_record() function resets the table->auto_increment_field_not_null
      variable before filling the record.
      The table->auto_increment_field_not_null variable is also reset by the
      open_table() function for a case if we missed some auto_increment_field_not_null
      handling bug.
      Now the table->auto_increment_field_not_null is reset at the end of the
      mysql_load() function.
      
      Reset the table->auto_increment_field_not_null variable after each
      write_row() call in the copy_data_between_tables() function.
      
      7c42232d
  22. 23 Mar, 2007 1 commit
    • aelkin/elkin@andrepl.(none)'s avatar
      Bug #27395 OPTION_STATUS_NO_TRANS_UPDATE is not preserved at the end of SF() · 2afa90b5
      aelkin/elkin@andrepl.(none) authored
      thd->options' OPTION_STATUS_NO_TRANS_UPDATE bit was not restored at the end of SF() invocation, where
      SF() modified non-ta table.
      As the result of this artifact it was not possible to detect whether there were any side-effects when
      top-level query ends. 
      If the top level query table was not modified and the bit is lost there would be no binlogging.
      
      Fixed with preserving the bit inside of thd->no_trans_update struct. The struct agregates two bool flags
      telling whether the current query and the current transaction modified any non-ta table.
      The flags stmt, all are dropped at the end of the query and the transaction.
      2afa90b5
  23. 01 Mar, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#25122: Views based on a self-joined table aren't insertable. · 11588e5e
      evgen@moonbone.local authored
      When INSERT is done over a view the table being inserted into is 
      checked to be unique among all views tables. But if the view contains
      self-joined table an error will be thrown even if all tables are used under
      different aliases.
      
      The unique_table() function now also checks tables' aliases when needed.
      11588e5e
  24. 28 Feb, 2007 1 commit
    • bar@mysql.com's avatar
      Bug#15126 character_set_database is not replicated (LOAD DATA INFILE need it) · dd0c43d5
      bar@mysql.com authored
      This patch fixes problem that LOAD DATA could use different
      character sets when loading files on master and on slave sides:
      - Adding replication of thd->variables.collation_database
      - Adding optional character set clause into LOAD DATA
      
      Note, the second way, with explicit CHARACTER SET clause
      should be the recommended way to load data using an alternative
      character set.
      The old way, using "SET @@character_set_database=xxx" should be
      gradually depricated.
      dd0c43d5
  25. 26 Feb, 2007 1 commit
  26. 14 Feb, 2007 1 commit
  27. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  28. 23 Dec, 2006 1 commit
  29. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  30. 07 Dec, 2006 2 commits
  31. 06 Dec, 2006 1 commit
  32. 02 Dec, 2006 1 commit
  33. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  34. 02 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID · 5ea8adfa
      kroki/tomash@moonlight.intranet authored
      Non-upper-level INSERTs (the ones in the body of stored procedure,
      stored function, or trigger) into a table that have AUTO_INCREMENT
      column didn't affected the result of LAST_INSERT_ID() on this level.
      
      The problem was introduced with the fix of bug 6880, which in turn was
      introduced with the fix of bug 3117, where current insert_id value was
      remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
      returned from that function until it was reset before the next
      _upper-level_ statement (bug 6880).
      
      The fix for bug#21726 brings back the behaviour of version 4.0, and
      implements the following: remember insert_id value at the beginning
      of the statement or expression (which at that point equals to
      the first insert_id value generated by the previous statement), and
      return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
      
      Thus, the value returned by LAST_INSERT_ID() is not affected by values
      generated by current statement, nor by LAST_INSERT_ID(expr) calls in
      this statement.
      
      Version 5.1 does not have this bug (it was fixed by WL 3146).
      5ea8adfa
  35. 05 Sep, 2006 1 commit
    • guilhem@gbichot3.local's avatar
      Fix for BUG#11151 "LOAD DATA INFILE commits transaction in 5.0". · e4d3595b
      guilhem@gbichot3.local authored
      In 5.0 we made LOAD DATA INFILE autocommit in all engines, while
      only NDB wanted that. Users and trainers complained that it affected
      InnoDB and was a change compared to 4.1 where only NDB autocommitted.
      To revert to the behaviour of 4.1, we move the autocommit logic out of mysql_load() into
      ha_ndbcluster::external_lock().
      The result is that LOAD DATA INFILE commits all uncommitted changes
      of NDB if this is an NDB table, its own changes if this is an NDB
      table, but does not affect other engines.
      Note: even though there is no "commit the full transaction at end"
      anymore, LOAD DATA INFILE stays disabled in routines (re-entrency
      problems per a comment of Pem).
      Note: ha_ndbcluster::has_transactions() does not give reliable results
      because it says "yes" even if transactions are disabled in this engine...
      e4d3595b