1. 06 Jun, 2007 3 commits
  2. 05 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28778: Wrong result of BETWEEN when comparing a DATETIME field with an · 0a91c7cc
      evgen@moonbone.local authored
      integer constants.
      
      This bug is introduced by the fix for bug#16377. Before the fix the 
      Item_func_between::fix_length_and_dec method converted the second and third
      arguments to the type of the first argument if they were constant and the first
      argument is of the DATE/DATETIME type. That approach worked well for integer
      constants and sometimes produced bad result for string constants. The fix for
      the bug#16377 wrongly removed that code at all and as a result of this the
      comparison of a DATETIME field and an integer constant was carried out in a
      wrong way and sometimes led to wrong result sets.
      
      Now the Item_func_between::fix_length_and_dec method converts the second and
      third arguments to the type of the first argument if they are constant, the
      first argument is of the DATE/DATETIME type and the DATETIME comparator isn't
      applicable.
      0a91c7cc
  3. 04 Jun, 2007 1 commit
  4. 03 Jun, 2007 8 commits
  5. 02 Jun, 2007 8 commits
  6. 01 Jun, 2007 6 commits
  7. 31 May, 2007 13 commits
    • gshchepa/uchum@gleb.loc's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 5d15377d
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/mysql-5.0-opt
      5d15377d
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/mysql-5.0-opt-27827-fresh · 92737068
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/mysql-5.0-opt
      92737068
    • gshchepa/uchum@gleb.loc's avatar
      sql_view.cc: · d6a0bbf2
      gshchepa/uchum@gleb.loc authored
        Additional patch for bug #28244 to workaround valgrind warnings.
      d6a0bbf2
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · df3b7082
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/28494-bug-5.0-opt-mysql
      df3b7082
    • evgen@moonbone.local's avatar
      Bug#28494: Grouping by Item_func_set_user_var produces incorrect result. · f70ae3a6
      evgen@moonbone.local authored
      The end_update() function uses the Item::save_org_in_field() function to
      save original values of items into the group buffer. But for the 
      Item_func_set_user_var this method was mapped to the save_in_field method.
      The latter function wrongly decides to use the result_field. This leads to
      saving incorrect value in the grouping buffer and wrong result of the whole
      query.
      
      The can_use_result_field argument of the bool type is added to the
      Item_func_set_user_var::save_in_field() function. If it is set to FALSE
      then the item's result field won't be used. Otherwise it will be detected
      whether the result field will be used (old behaviour).
      Two wrapping functions for the function above are added to the 
      Item_func_set_user_var class:
      the save_in_field(Field *field, bool no_conversions) - it calls the above
      function with the can_use_result_field set to TRUE.
      the save_org_in_field(Field *field) - same, but the can_use_result_field
      is set to FALSE.
      f70ae3a6
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #27827. · cab4ca9c
      gshchepa/uchum@gleb.loc authored
      ON conditions from JOIN expression were ignored at CHECK OPTION
      check when updating a multi-table view with CHECK OPTION.
      
      The st_table_list::prep_check_option function has been
      modified to to take into account ON conditions at CHECK OPTION check
      It was also changed to build the check option condition only once
      for any update used in PS/SP.
      cab4ca9c
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/mysql-5.0-opt · 55833d3a
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/mysql-5.0-opt-28244
      55833d3a
    • gshchepa/uchum@gleb.loc's avatar
      sql_view.cc: · f690d759
      gshchepa/uchum@gleb.loc authored
        Patch to eliminate compilation warning.
      f690d759
    • gshchepa/uchum@gleb.loc's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 36244941
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/mysql-5.0-opt
      36244941
    • gshchepa/uchum@gleb.loc's avatar
      Merge gleb.loc:/home/uchum/work/bk/mysql-5.0-opt · 19d513de
      gshchepa/uchum@gleb.loc authored
      into  gleb.loc:/home/uchum/work/bk/mysql-5.0-opt-28244
      19d513de
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28244. · 12d43d55
      gshchepa/uchum@gleb.loc authored
      When the same VIEW was created at the master side twice,
      malformed (truncated after the word 'AS') query string 
      was forwarded to client side, so error messages on the
      master and client was different, and replication was
      broken.
      
      The mysql_register_view function call failed
      too early: fields of `view' output argument of this 
      function was not filled yet with correct data required
      for query replication.
      The mysql_register_view function also copied pointers to 
      local buffers into a memory allocated by the caller.
      12d43d55
    • mhansson@dl145s.mysql.com's avatar
      bug#27741: udf test fails on AIX < 5.3 · 3ee16518
      mhansson@dl145s.mysql.com authored
      problem #1: udf_example.so does not get built on AIX
      
      solution#1: build it yourself using
      cd sql; gcc  -g -I ../include/ -I /usr/include/ -lpthread  \
      -shared -o udf_example.so udf_example.c; mv udf_example.so \
      .libs/ 
      
      problem#2 (the bug): udf_example fails because it does not
      recognize the variable LD_LIBRARY_PATH when doing dl_open(),
      it looks at LIBPATH
      
      solution#2: add the library path to LIBPATH
      
      problem#3: udf_example returns the wrong result length since 
      it relies on strmov to return a pointer to the end of the 
      string that it copies. On AIX builds, where m_string.h is not
      included (m_string defines a macro expanding strmov to stpcpy),
      there is a macro expanding strmov to strcpy, which returns a 
      pointer to the first character.
      
      solution#3: define strmov as stpcpy.
      
      problem#4: #2 applies on hp-ux as well, but this platform
      looks at SHLIB_PATH
      
      solution#4: added the library path to SHLIB_PATH
      3ee16518
    • lars/lthalmann@dl145h.mysql.com's avatar
      Merge lthalmann@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 4e900099
      lars/lthalmann@dl145h.mysql.com authored
      into  mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl
      4e900099