An error occurred fetching the project authors.
  1. 21 Dec, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #33256: CREATE ... SELECT creates obsolete table · e4efb4a5
      gkodinov/kgeorge@macbook.gmz authored
       w/ Field_date instead of Field_newdate
        
      Field_date was still used in temp table creation.
      Fixed by using Field_newdate consistently throughout the server
      except when reading tables defined with older MySQL version.
      No test suite is possible because both Field_date and Field_newdate
      return the same values in all the metadata calls. 
      e4efb4a5
  2. 11 Dec, 2007 1 commit
    • mhansson/martin@linux-st28.site's avatar
      Bug#32848: Data type conversion bug in union subselects in MySQL 5.0.38 · 867a7865
      mhansson/martin@linux-st28.site authored
      There were two problems when inferring the correct field types resulting from
      UNION queries.
      - If the type is NULL for all corresponding fields in the UNION, the resulting 
        type would be NULL, while the type is BINARY(0) if there is just a single 
        SELECT NULL.
      - If one SELECT in the UNION uses a subselect, a temporary table is created
        to represent the subselect, and the result type defaults to a STRING type,
        hiding the fact that the type was unknown(just a NULL value).
      Fixed by remembering whenever a field was created from a NULL value and pass
      type NULL to the type coercion if that is the case, and creating a string field
      as result of UNION only if the type would otherwise be NULL.
      867a7865
  3. 08 Dec, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27545. · c04d3727
      igor@olga.mysql.com authored
      Both arguments of the function NAME_CONST must be constant expressions.
      This constraint is checked in the Item_name_const::fix_fields method. 
      Yet if the argument of the function was not a constant expression no
      error message was reported. As a result the client hanged waiting for a
      response.
      Now the function Item_name_const::fix_fields reports an error message
      when any of the additional context conditions imposed on the function
      NAME_CONST is not satisfied. 
      c04d3727
  4. 27 Nov, 2007 1 commit
  5. 20 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32400: Complex SELECT query returns correct result · 846cbf3c
      gkodinov/kgeorge@magare.gmz authored
       only on some occasions
      
      Referencing an element from the SELECT list in a WHERE 
      clause is not permitted. The namespace of the WHERE
      clause is the table columns only. This was not enforced
      correctly when resolving outer references in sub-queries.
      
      Fixed by not allowing references to aliases in a 
      sub-query in WHERE.
      846cbf3c
  6. 13 Nov, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #31562: HAVING and lower case · 3384d3e9
      gkodinov/kgeorge@magare.gmz authored
      The columns in HAVING can reference the GROUP BY and 
      SELECT columns. There can be "table" prefixes when
      referencing these columns. And these "table" prefixes
      in HAVING use the table alias if available.
      This means that table aliases are subject to the same
      storage rules as table names and are dependent on 
      lower_case_table_names in the same way as the table 
      names are.
      Fixed by :
      1. Treating table aliases as table names
      and make them lowercase when printing out the SQL
      statement for view persistence.
      2. Using case insensitive comparison for table 
      aliases when requested by lower_case_table_names
      3384d3e9
  7. 10 Nov, 2007 1 commit
  8. 23 Oct, 2007 1 commit
  9. 22 Oct, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28687: Search fails on '0000-00-00' date after sql_mode change · 52b35112
      gkodinov/kgeorge@magare.gmz authored
      When doing indexed search the server constructs a key image for 
      faster comparison to the stored keys. While doing that it must not
      perform (and stop if they fail) the additional date checks that can 
      be turned on by the SQL mode because there already may be values in 
      the table that don't comply with the error checks.
      Fixed by ignoring these SQL mode bits while making the key image.
      52b35112
  10. 21 Oct, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Bug #28550 "Potential bugs related to the return type of the CHAR function". · 34984111
      kaa@polly.(none) authored
        
      Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account.
        
      This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().
      34984111
  11. 15 Oct, 2007 1 commit
  12. 11 Oct, 2007 1 commit
    • gluh@mysql.com/eagle.(none)'s avatar
      Bug#30981 CHAR(0x41 USING ucs2) doesn't add leading zero · db39976a
      gluh@mysql.com/eagle.(none) authored
      Bug#30982 CHAR(..USING..) can return a not-well-formed string
      Bug#30986 Character set introducer followed by a HEX string can return bad result
      check_well_formed_result moved to Item from Item_str_func
      fixed Item_func_char::val_str for proper ucs symbols converting
      added check for well formed strings for correct conversion of constants with underscore
      charset
      db39976a
  13. 05 Oct, 2007 1 commit
  14. 04 Oct, 2007 1 commit
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #31155 gis types in union'd select cause crash. · 16db036d
      holyfoot/hf@mysql.com/hfmain.(none) authored
      We use get_geometry_type() call to decide the exact type
      of a geometry field to be created (POINT, POLYGON etc)
      Though this function was only implemented for few items.
      In the bug's case we need to call this function for the
      Item_sum instance, where it was not implemented, what is
      the reason of the crash.
      Fixed by implementing virtual Item::get_geometry_type(),
      so it can be called for any Item.
      16db036d
  15. 28 Sep, 2007 1 commit
  16. 13 Sep, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #27695. · e4eadcfb
      gshchepa/uchum@gleb.loc authored
      Declaring an all space column name in the SELECT FROM DUAL or in a view
      leads to misleading warning message:
      "Leading spaces are removed from name ' '".
      
      The Item::set_name method has been modified to raise warnings like
      "Name ' ' has become ''" in case of the truncation of an all
      space identifier to an empty string identifier instead of the
      "Leading spaces are removed from name ' '" warning message.
      e4eadcfb
  17. 20 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30287. · 5d3809c2
      gshchepa/uchum@gleb.loc authored
      The server created temporary tables for filesort in the working directory
      instead of the specified tmpdir directory.
      5d3809c2
  18. 06 Aug, 2007 1 commit
  19. 03 Aug, 2007 1 commit
    • bar@mysql.com/bar.myoffice.izhnet.ru's avatar
      Bug#28875 Conversion between ASCII and LATIN1 charsets does not function · 4eebfd09
      bar@mysql.com/bar.myoffice.izhnet.ru authored
      (Regression, caused by a patch for the bug 22646).
      Problem: when result type of date_format() was changed from
      binary string to character string, mixing date_format()
      with a ascii column in CONCAT() stopped to work.
      Fix:
      - adding "repertoire" flag into DTCollation class,
      to mark items which can return only pure ASCII strings.
      - allow character set conversion from pure ASCII to other character sets.
      4eebfd09
  20. 29 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30120. · 1eb20fc0
      gshchepa/uchum@gleb.loc authored
      SP with local variables with non-ASCII names crashed the server.
      
      The server replaces SP local variable names with NAME_CONST calls
      when putting statements into the binary log. It used UTF8-encoded
      item names as variable names for the replacement inside NAME_CONST
      calls. However, statement string may be encoded by any
      known character set by the SET NAMES statement.
      The server used byte length of UTF8-encoded names to increment
      the position in the query string that led to array index overrun.
      1eb20fc0
  21. 27 Jul, 2007 1 commit
  22. 06 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Remove typedef st_table_list TABLE_LIST and always use name 'TABLE_LIST'. · a33bc2c2
      kostja@bodhi.(none) authored
      The need arose when working on Bug 26141, where it became
      necessary to replace TABLE_LIST with its forward declaration in a few
      headers, and this involved a lot of s/TABLE_LIST/st_table_list/.
      Although other workarounds exist, this patch is in line
      with our general strategy of moving away from typedef-ed names.
      Sometime in future we might also rename TABLE_LIST to follow the
      coding style, but this is a huge change.
      a33bc2c2
  23. 29 Jun, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29205. · 3c260e4a
      gshchepa/uchum@gleb.loc authored
      When a UNION statement forced conversion of an UTF8
      charset value to a binary charset value, the byte
      length of the result values was truncated to the
      CHAR_LENGTH of the original UTF8 value.
      3c260e4a
  24. 20 Jun, 2007 2 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #29104: assertion abort for grouping queries using views. · c6cc5096
      igor@olga.mysql.com authored
      The abort happened when a query contained a conjunctive predicate
      of the form 'view column = constant' in the WHERE condition and 
      the grouping list also contained a reference to a view column yet
      a different one.
      
      Removed the failing assertion as invalid in a general case.
      
      Also fixed a bug that prevented applying some optimization for grouping
      queries using views. If the WHERE condition of such a query contains
      a conjunctive condition of the form 'view column = constant' and
      this view column is used in the grouping list then grouping by this
      column can be eliminated. The bug blocked performing this elimination.
      c6cc5096
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28898. · 2379f977
      gshchepa/uchum@gleb.loc authored
      For a join query with GROUP BY and/or ORDER BY and a view reference
      in the FROM list the metadata erroneously showed empty table aliases
      and database names for the view columns.
      2379f977
  25. 07 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28763: Selecting geometry fields in UNION caused server crash. · eb9e174b
      evgen@moonbone.local authored
      This bug was introduced by the fix for the bug#27300. In this fix a section
      of code was added to the Item::tmp_table_field_from_field_type method.
      This section intended to create Field_geom fields for the Item_geometry_func
      class and its descendants. In order to get the geometry type of the current
      item it casted "this" to the Item_geometry_func* type. But the
      Item::tmp_table_field_from_field_type method is also used for creation of
      fields for UNION and in this case this method is called for an object of the
      Item_type_holder class and the cast to the Item_geometry_func* type causes 
      a server crash.
      
      Now the Item::tmp_table_field_from_field_type method correctly works when it's
      called for both the Item_type_holder and the Item_geometry_func classes.
      The new geometry_type variable is added to the Item_type_holder class.
      The new method called get_geometry_type is added to the Item_field
      and the Field classes. It returns geometry type from the field for the
      Item_field and the Field_geom classes and fails an assert for other Field
      descendants.
      eb9e174b
  26. 18 May, 2007 2 commits
  27. 17 May, 2007 1 commit
  28. 16 May, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · a65d12a8
      msvensson@pilot.blaudden authored
         
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
       
      a65d12a8
  29. 04 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27759: Wrong DATE/DATETIME comparison in LEAST()/GREATEST() functions. · 239f727b
      evgen@moonbone.local authored
      The LEAST/GREATEST functions compared DATE/DATETIME values as
      strings which in some cases could lead to a wrong result.
      
      A new member function called cmp_datetimes() is added to the
      Item_func_min_max class. It compares arguments in DATETIME context
      and returns index of the least/greatest argument.
      The Item_func_min_max::fix_length_and_dec() function now detects when
      arguments should be compared in DATETIME context and sets the newly
      added flag compare_as_dates. It indicates that the cmp_datetimes() function
      should be called to get a correct result.
      Item_func_min_max::val_xxx() methods are corrected to call the
      cmp_datetimes() function when needed.
      Objects of the Item_splocal class now stores and reports correct original
      field type.
      239f727b
  30. 27 Apr, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21513 (SP having body starting with quoted label rendered unusable) · 012f841f
      malff/marcsql@weblab.(none) authored
      Before this fix, the parser would sometime change where a token starts by
      altering Lex_input_string::tok_start, which later confused the code in
      sql_yacc.yy that needs to capture the source code of a SQL statement,
      like to represent the body of a stored procedure.
      
      This line of code in sql_lex.cc :
      
      case MY_LEX_USER_VARIABLE_DELIMITER:
        lip->tok_start= lip->ptr; // Skip first `
      
      would <skip the first back quote> ... and cause the bug reported.
      
      In general, the responsibility of sql_lex.cc is to *find* where token are
      in the SQL text, but is *not* to make up fake or incomplete tokens.
      With a quoted label like `my_label`, the token starts on the first quote.
      Extracting the token value should not change that (it did).
      
      With this fix, the lexical analysis has been cleaned up to not change
      lip->tok_start (in the case found for this bug).
      
      The functions get_token() and get_quoted_token() now have an extra
      parameters, used when some characters from the beginning of the token need
      to be skipped when extracting a token value, like when extracting 'AB' from
      '0xAB', for example, for a HEX_NUM token.
      
      This exposed a bad assumption in Item_hex_string and Item_bin_string,
      which has been fixed:
      
      The assumption was that the string given, 'AB', was in fact preceded in
      memory by '0x', which might be false (it can be preceded by "x'" and
      followed by "'" -- or not be preceded by valid memory at all)
      
      If a name is needed for Item_hex_string or Item_bin_string, the name is
      taken from the original and true source code ('0xAB'), and assigned in
      the select_item rule, instead of relying on assumptions related to how
      memory is used.
      012f841f
  31. 26 Apr, 2007 2 commits
    • evgen@moonbone.local's avatar
      Bug#27590: Wrong DATE/DATETIME comparison. · 4747fa0c
      evgen@moonbone.local authored
      DATE and DATETIME can be compared either as strings or as int. Both
      methods have their disadvantages. Strings can contain valid DATETIME value
      but have insignificant zeros omitted thus became non-comparable with
      other DATETIME strings. The comparison as int usually will require conversion
      from the string representation and the automatic conversion in most cases is
      carried out in a wrong way thus producing wrong comparison result. Another
      problem occurs when one tries to compare DATE field with a DATETIME constant.
      The constant is converted to DATE losing its precision i.e. losing time part.
      
      This fix addresses the problems described above by adding a special
      DATE/DATETIME comparator. The comparator correctly converts DATE/DATETIME
      string values to int when it's necessary, adds zero time part (00:00:00)
      to DATE values to compare them correctly to DATETIME values. Due to correct
      conversion malformed DATETIME string values are correctly compared to other
      DATE/DATETIME values.
      
      As of this patch a DATE value equals to DATETIME value with zero time part.
      For example '2001-01-01' equals to '2001-01-01 00:00:00'.
      
      The compare_datetime() function is added to the Arg_comparator class.
      It implements the correct comparator for DATE/DATETIME values.
      Two supplementary functions called get_date_from_str() and get_datetime_value()
      are added. The first one extracts DATE/DATETIME value from a string and the
      second one retrieves the correct DATE/DATETIME value from an item.
      The new Arg_comparator::can_compare_as_dates() function is added and used
      to check whether two given items can be compared by the compare_datetime()
      comparator.
      Two caching variables were added to the Arg_comparator class to speedup the
      DATE/DATETIME comparison.
      One more store() method was added to the Item_cache_int class to cache int
      values.
      The new is_datetime() function was added to the Item class. It indicates
      whether the item returns a DATE/DATETIME value.
      4747fa0c
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27363: · bfa29e17
      gkodinov/kgeorge@magare.gmz authored
      Validity checks for nested set functions
      were not taking into account that the enclosed
      set function may be on a nest level that is
      lower than the nest level of the enclosing set
      function.
      Fixed by :
       - propagating max_sum_func_level
      up the enclosing set functions chain.
       - updating the max_sum_func_level of the 
         enclosing set function when the enclosed set
         function is aggregated above or on the same
         nest level of as the level of the enclosing 
         set function.
       - updating the max_arg_level of the enclosing
         set function on a reference that refers to
         an item above or on the same nest level
         as the level of the enclosing set function.
       - Treating both Item_field and Item_ref as possibly
         referencing items from outer nest levels.
      bfa29e17
  32. 15 Apr, 2007 2 commits
    • evgen@moonbone.local's avatar
      item.cc: · 7d71d580
      evgen@moonbone.local authored
        Fix warning after fix for bug#27321.
      7d71d580
    • evgen@moonbone.local's avatar
      Bug#27321: Wrong subquery result in a grouping select. · 3113ce63
      evgen@moonbone.local authored
      The Item_outer_ref class based on the Item_direct_ref class was always used
      to represent an outer field. But if the outer select is a grouping one and the 
      outer field isn't under an aggregate function which is aggregated in that
      outer select an Item_ref object should be used to represent such a field.
      If the outer select in which the outer field is resolved isn't grouping then
      the Item_field class should be used to represent such a field.
      This logic also should be used for an outer field resolved through its alias
      name.
      
      Now the Item_field::fix_outer_field() uses Item_outer_field objects to
      represent aliased and non-aliased outer fields for grouping outer selects
      only.
      Now the fix_inner_refs() function chooses which class to use to access outer
      field - the Item_ref or the Item_direct_ref. An object of the chosen class
      substitutes the original field in the Item_outer_ref object.
      The direct_ref and the found_in_select_list fields were added to the
      Item_outer_ref class.
      3113ce63
  33. 28 Mar, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27300: · c3eb3f70
      gkodinov/kgeorge@magare.gmz authored
        Geometry fields have a result type string and a 
        special subclass to cater for the differences
        between them and the base class (just like 
        DATE/TIME).
        When creating temporary tables for results of 
        functions that return results of type GEOMETRY
        we must construct fields of the derived class 
        instead of the base class.
        Fixed by creating a GEOMETRY field (Field_geom) 
        instead of a generic BLOB (Field_blob) in temp 
        tables for the results of GIS functions that 
        have GEOMETRY return type (Item_geometry_func).
      c3eb3f70
  34. 22 Mar, 2007 3 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #27229: crash when a set function aggregated in outer · 8f9178e8
      igor@olga.mysql.com authored
      context was used as an argument of GROUP_CONCAT.
      Ensured correct setting of the depended_from field in references
      generated for set functions aggregated in outer selects.
      A wrong value of this field resulted in wrong maps returned by 
      used_tables() for these references.
      Made sure that a temporary table field is added for any set function
      aggregated in outer context when creation of a temporary table is 
      needed to execute the inner subquery. 
      8f9178e8
    • jani@ua141d10.elisa.omakaista.fi's avatar
      5c542a46
    • mhansson/martin@linux-st28.site's avatar
      Bug #24791: Union with AVG-groups generates wrong results · 50077b6d
      mhansson/martin@linux-st28.site authored
      The problem in this bug is when we create temporary tables. When
      temporary tables are created for unions, there is some 
      inferrence being carried out regarding the type of the column.
      Whenever this column type is inferred to be REAL (i.e. FLOAT or
      DOUBLE), MySQL will always try to maintain exact precision, and
      if that is not possible (there are hardware limits, since FLOAT
      and DOUBLE are stored as approximate values) will switch to
      using approximate values. The problem here is that at this point
      the information about number of significant digits is not 
      available. Furthermore, the number of significant digits should
      be increased for the AVG function, however, this was not properly 
      handled. There are 4 parts to the problem:
      
      #1: DOUBLE and FLOAT fields don't display their proper display 
      lengths in max_display_length(). This is hard-coded as 53 for 
      DOUBLE and 24 for FLOAT. Now changed to instead return the 
      field_length.
      
      #2: Type holders for temporary tables do not preserve the 
      max_length of the Item's from which they are created, and is 
      instead reverted to the 53 and 24 from above. This causes 
      *all* fields to get non-fixed significant digits.
      
      #3: AVG function does not update max_length (display length)
      when updating number of decimals.
      
      #4: The function that switches to non-fixed number of 
      significant digits should use DBL_DIG + 2 or FLT_DIG + 2 as 
      cut-off values (Since fixed precision does not use the 'e' 
      notation)
      
      Of these points, #1 is the controversial one, but this 
      change is preferred and has been cleared with Monty. The 
      function causes quite a few unit tests to blow up and they had
      to b changed, but each one is annotated and motivated. We 
      frequently see the magical 53 and 24 give way to more relevant
      numbers.
      50077b6d