An error occurred fetching the project authors.
  1. 27 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#22584: last_insert_id not updated after inserting a record through · 0e0f7a04
      kroki/tomash@moonlight.intranet authored
      a updatable view.
      
      When there's a VIEW on a base table that have AUTO_INCREMENT column, and
      this VIEW doesn't provide an access such column, after INSERT to such
      VIEW LAST_INSERT_ID() did not return the value just generated.
      
      This behaviour is intended and correct, because if the VIEW doesn't list
      some columns then these columns are effectively hidden from the user,
      and so any side effects of inserting default values to them.
      
      However, there was a bug that such statement inserting into a view would
      reset LAST_INSERT_ID() instead of leaving it unchanged.
      
      This patch restores the original value of LAST_INSERT_ID() instead of
      resetting it to zero.
      0e0f7a04
  2. 23 Oct, 2006 1 commit
  3. 17 Oct, 2006 1 commit
  4. 12 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#20953: create proc with a create view that uses local vars/params · 591c06d4
      kroki/tomash@moonlight.intranet authored
                 should fail to create
      
      The problem was that this type of errors was checked during view
      creation, which doesn't happen when CREATE VIEW is a statement of
      a created stored routine.
      
      The solution is to perform the checks at parse time.  The idea of the
      fix is that the parser checks if a construction just parsed is allowed
      in current circumstances by testing certain flags, and this flags are
      reset for VIEWs.
      
      The side effect of this change is that if the user already have
      such bogus routines, it will now get a error when trying to do
      
        SHOW CREATE PROCEDURE proc;
      
      (and some other) and when trying to execute such routine he will get
      
        ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
      
      However there should be very few such users (if any), and they may
      (and should) drop these bogus routines.
      591c06d4
  5. 10 Oct, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      Fix after manial merge. · b2c6ff7a
      kroki/tomash@moonlight.intranet authored
      b2c6ff7a
    • kroki/tomash@moonlight.intranet's avatar
      Bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. · 4a28f8f1
      kroki/tomash@moonlight.intranet authored
      In a trigger or a function used in a statement it is possible to do
      SELECT from a table being modified by the statement.  However,
      encapsulation of such SELECT into a view and selecting from a view
      instead of direct SELECT was not possible.
      
      This happened because tables used by views (which in their turn
      were used from functions/triggers) were not excluded from checks
      in unique_table() routine as it happens for the rest of tables
      added to the statement table list for prelocking.
      
      With this fix we ignore all such tables in unique_table(), thus
      providing consistency: inside a trigger or a functions SELECT from
      a view may be used where plain SELECT is allowed.  Modification of
      the same table from function or trigger is still disallowed.  Also,
      this patch doesn't affect the case where SELECT from the table being
      modified is done outside of function of trigger, such SELECTs are
      still disallowed (this limitation and visibility problem when function
      select from a table being modified are subjects of bug 21326).  See
      also bug 22427.
      4a28f8f1
  6. 29 Sep, 2006 1 commit
    • holyfoot/hf@mysql.com/deer.(none)'s avatar
      bug #16813 (WITH CHECK OPTION fails with UPDATE) · 3474fc9a
      holyfoot/hf@mysql.com/deer.(none) authored
      We use the condition from CHECK OPTION twice handling UPDATE command.
      First we construnct 'update_cond' AND 'option_cond'
      condition to select records to be updated, then we check the
      'option_cond' for the updated row.
      The problem is that first 'AND' condition is optimized during the 'select'
      which can break 'option_cond' structure, so it will be unusable for
      the sectond use - to check the updated row.
      Possible soultion is either use copy of the condition in the first
      use or to make optimization less traumatic for the operands.
      I picked the first one. 
      3474fc9a
  7. 28 Sep, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#5505: Wrong error message on INSERT into a view · f6fbbf20
      evgen@moonbone.local authored
      On an INSERT into an updatable but non-insertable view an error message was
      issued stating the view being not updatable. This can lead to a confusion of a
      user.
      
      A new error message is introduced. Is is showed when a user tries to insert
      into a non-insertable view.
      f6fbbf20
  8. 25 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21646. · a661bdda
      igor@rurik.mysql.com authored
      Presence of a subquery in the ON expression of a join 
      should not block merging the view that contains this join.
      Before this patch the such views were converted into 
      into temporary table views.
      a661bdda
  9. 18 Sep, 2006 1 commit
  10. 14 Sep, 2006 1 commit
    • evgen@sunlight.local's avatar
      type_date.result: · 058d2296
      evgen@sunlight.local authored
        Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN
        Corrected a test case after removal of fix for bug#16377
      query_cache.result, func_time.test, view.result, view.test, func_time.result:
        Corrected a test case after removal of fix for bug#16377
      type_date.test:
        Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN
         Corrected a test case after removal of fix for bug#16377
      item_cmpfunc.cc:
        Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
      058d2296
  11. 06 Sep, 2006 1 commit
  12. 29 Aug, 2006 2 commits
  13. 24 Aug, 2006 1 commit
  14. 23 Aug, 2006 2 commits
  15. 17 Aug, 2006 1 commit
  16. 15 Aug, 2006 2 commits
    • evgen@sunlight.local's avatar
      Fixed bug#21261: Wrong access rights was required for an insert into a view · dd9a0770
      evgen@sunlight.local authored
      SELECT right instead of INSERT right was required for an insert into to a view.
      This wrong behaviour appeared after the fix for bug #20989. Its intention was
      to ask only SELECT right for all tables except the very first for a complex
      INSERT query. But that patch has done it in a wrong way and lead to asking 
      a wrong access right for an insert into a view.
      
      The setup_tables_and_check_access() function now accepts two want_access
      parameters. One will be used for the first table and the second for other
      tables.
      dd9a0770
    • evgen@moonbone.local's avatar
      Fixed bug#15950: NOW() optimized away in VIEWs · 8364a646
      evgen@moonbone.local authored
      This bug is a side-effect of bug fix #16377. NOW() is optimized in
      BETWEEN to integer constants to speed up query execution. When view is being
      created it saves already modified query and thus becomes wrong.
      
      The agg_cmp_type() function now substitutes constant result DATE/TIME functions 
      for their results only if the current query isn't CREATE VIEW or SHOW CREATE
      VIEW.
      8364a646
  17. 02 Aug, 2006 1 commit
    • svoj@may.pils.ru's avatar
      BUG#14770 - LOAD DATA INFILE doesn't respect default values for · 6c6f435b
      svoj@may.pils.ru authored
                  columns
      Fixed confusing warning.
      
      Quoting INSERT section of the manual:
      ----
      Inserting NULL into a column that has been declared NOT NULL. For
      multiple-row INSERT statements or INSERT INTO ... SELECT statements, the
      column is set to the implicit default value for the column data type. This
      is 0 for numeric types, the empty string ('') for string types, and the
      "zero" value for date and time types. INSERT INTO ... SELECT statements are
      handled the same way as multiple-row inserts because the server does not
      examine the result set from the SELECT to see whether it returns a single
      row. (For a single-row INSERT, no warning occurs when NULL is inserted into
      a NOT NULL column. Instead, the statement fails with an error.)
      ----
      This is also true for LOAD DATA INFILE. For INSERT user can specify
      DEFAULT keyword as a value to set column default. There is no similiar
      feature available for LOAD DATA INFILE.
      6c6f435b
  18. 31 Jul, 2006 2 commits
  19. 25 Jul, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called · f5b0dd6a
      gkodinov/kgeorge@macbook.gmz authored
        When executing INSERT over a view with calculated columns it was assuming all
        elements of the fields collection are actually Item_field instances.
        This may not be true when inserting into a view and that view has columns that are 
        such expressions that allow updating (like setting a collation for example).
        Corrected to access field information through the filed_for_view_update() function and 
        retrieve correctly the field info even for "update-friendly" non-Item_field items.
      f5b0dd6a
  20. 20 Jul, 2006 1 commit
  21. 19 Jul, 2006 1 commit
  22. 14 Jul, 2006 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #19714. · f6080640
      igor@olga.mysql.com authored
      DESCRIBE returned the type BIGINT for a column of a view if the column
      was specified by an expression over values of the type INT.
          
      E.g. for the view defined as follows:
        CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1
      DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are
      columns of the INT type.
      At the same time DESCRIBE returned type INT for the only column of the table
      defined by the statement:
        CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1.
          
      This inconsistency was removed by the patch.
      
      Now the code chooses between INT/BIGINT depending on the
      precision of the aggregated column type.
       
      Thus both DESCRIBE commands above returns type INT for v1 and t2.
       
      f6080640
  23. 06 Jul, 2006 1 commit
  24. 04 Jul, 2006 1 commit
    • gkodinov@mysql.com's avatar
      Bug #16110: insert permitted into view col w/o default value · b64089e6
      gkodinov@mysql.com authored
      When compiling INSERT statements the check whether columns are provided values
      depends on the flag whether a field is used in that query (Field::query_id).
      However the check for updatability of VIEW columns (check_view_insertability())
      was calling fix_fields() and thus setting the Field::query_id even for the 
      view fields that are not referenced in the current INSERT statement.
      So the correct check for columns without default values 
      ( check_that_all_fields_are_given_values() ) is assuming that all the VIEW
      columns were mentioned in the INSERT field list and was issuing no 
      warnings or errors.
      Fixed check_view_insertability() to turn off the flag whether or not to set
      Field::query_id (THREAD::set_query_id) before calling fix fields and restore
      it when it's done.
      b64089e6
  25. 27 Jun, 2006 1 commit
  26. 01 Jun, 2006 1 commit
  27. 22 May, 2006 1 commit
  28. 21 May, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #19089. · 12e53358
      igor@rurik.mysql.com authored
      When a CREATE TABLE command created a table from a materialized
      view id does not inherit default values from the underlying table.
      Moreover the temporary table used for the view materialization
      does not inherit those default values.
      In the case when the underlying table contained ENUM fields it caused
      misleading error messages. In other cases the created table contained
      wrong default values.
      The code was modified to ensure inheritance of default values for
      materialized views.
      12e53358
  29. 17 May, 2006 2 commits
    • evgen@moonbone.local's avatar
      Fixed bug#19077: A nested materialized derived table is used before being populated. · 1d820585
      evgen@moonbone.local authored
      The convert_constant_item() function converts constant items to ints on
      prepare phase to optimize execution speed. In this case it tries to evaluate
      subselect which contains a derived table and is contained in a derived table. 
      All derived tables are filled only after all derived tables are prepared.
      So evaluation of subselect with derived table at the prepare phase will
      return a wrong result.
      
      A new flag with_subselect is added to the Item class. It indicates that
      expression which this item represents is a subselect or contains a subselect.
      It is set to 0 by default. It is set to 1 in the Item_subselect constructor
      for subselects.
      For Item_func and Item_cond derived classes it is set after fixing any argument
      in Item_func::fix_fields() and Item_cond::fix_fields accordingly.
      The convert_constant_item() function now doesn't convert a constant item
      if the with_subselect flag set in it. 
      1d820585
    • igor@rurik.mysql.com's avatar
      Fixed bug #19573. · 767d25da
      igor@rurik.mysql.com authored
      The select statement that specified a view could be
      slightly changed when the view was saved in a frm file.
      In particular references to an alias name in the HAVING
      clause could be substituted for the expression named by
      this alias.
      This could result in an error message for a query of
      the form SELECT * FROM <view>. Yet no such message
      appeared when executing the query specifying the view.
      767d25da
  30. 13 May, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #19490. The bug that caused server crash manifested · 90f22704
      igor@rurik.mysql.com authored
      itself when executing queries referring to a view with GROUP BY
      an expression containing non-constant interval.
      It happened because Item_date_add_interval::eq neglected the
      fact that the method can be applied to an expression of the form
          date(col) + interval time_to_sec(col) second
      at the time when col could not be evaluated yet.
      An attempt to evaluate time_to_sec(col) in this method resulted
      in a crash.
      90f22704
  31. 11 May, 2006 1 commit
    • gkodinov@mysql.com's avatar
      BUG#7549: Missing error message for invalid view selection with subquery. · 0486cfbe
      gkodinov@mysql.com authored
      When a view statement is compiled on CREATE VIEW time, most of the 
      optimizations should not be done. Finding the right optimization 
      for a subquery is one of them.
      Unfortunately the optimizer is resolving the column references of 
      the left expression of IN subqueries in the process of deciding 
      witch optimization to use (if needed). So there should be a 
      special case in Item_in_subselect::fix_fields() : check the 
      validity of the left expression of IN subqueries in CREATE VIEW 
      mode and then proceed as normal. 
      0486cfbe
  32. 26 Apr, 2006 1 commit
  33. 22 Apr, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#15153 "CONVERT_TZ() is not allowed in all places in VIEWs". · c77d5a0e
      dlenev@mysql.com authored
      Error was emitted when one tried to select information from view which used
      merge algorithm and which also had CONVERT_TZ() function in its select list.
      
      This bug was caused by wrong assumption that global table list for view
      which is handled using merge algorithm begins from tables belonging to
      the main select of this view. Nowadays the above assumption is not true only
      when one uses convert_tz() function in view's select list, but in future
      other cases may be added (for example we may support merging of views
      with subqueries in select list one day). Relying on this false assumption
      led to the usage of wrong table list for field lookups and therefor errors. 
      
      With this fix we explicitly use pointer to the beginning of main select's
      table list.
      c77d5a0e
  34. 13 Apr, 2006 1 commit