An error occurred fetching the project authors.
  1. 26 Mar, 2008 1 commit
    • gshchepa/uchum@host.loc's avatar
      Fixed bug #35193. · 2dcec449
      gshchepa/uchum@host.loc authored
      View definition as SELECT ... FROM DUAL WHERE ... has
      valid syntax, but use of such view in SELECT or
      SHOW CREATE VIEW syntax causes unexpected syntax error.
      
      Server omits FROM DUAL clause when storing view body
      string in a .frm file for further evaluation.
      However, syntax of SELECT-witout-FROM query is more
      restrictive than SELECT FROM DUAL syntax, and doesn't
      allow the WHERE clause.
      
      NOTE: this syntax difference is not documented.
      
      
      View registration procedure has been modified to
      preserve original structure of view's body.
      2dcec449
  2. 22 Feb, 2008 1 commit
    • kaa@kaamos.(none)'s avatar
      Fix for bug #33049: Assert while running test-as3ap test(mysql-bench · 0a29b8b0
      kaa@kaamos.(none) authored
                          suite)
      
      Under some circumstances a combination of aggregate functions and
      GROUP BY in a SELECT query over a VIEW could lead to incorrect
      calculation of the result type of the aggregate function. This in
      turn could result in incorrect results, or assertion failures on debug
      builds.
      
      Fixed by changing the logic in Item_sum_hybrid::fix_fields() so that
      the argument's item is dereferenced before calling its type() method.
      0a29b8b0
  3. 21 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#34337: Server crash when Altering a view using · f5cb5fdc
      anozdrin/alik@quad. authored
      a table name.
        
      The problem was that fill_defined_view_parts() did not return
      an error if a table is going to be altered. That happened if
      the table was already in the table cache. In that case,
      open_table() returned non-NULL value (valid TABLE-instance from
      the cache).
        
      The fix is to ensure that an error is thrown even if the table
      is in the cache.
      
      (This is a backport of the original patch for 5.1)
      f5cb5fdc
  4. 12 Feb, 2008 1 commit
    • kaa@mbp.'s avatar
      Fix for bug #33389: Selecting from a view into a table from within SP · 97c105cc
      kaa@mbp. authored
                          or trigger crashes server
      
      Under some circumstances a combination of VIEWs, subselects with outer
      references and PS/SP/triggers could lead to use of uninitialized memory
      and server crash as a result.
      
      Fixed by changing the code in Item_field::fix_fields() so that in cases
      when the field is a VIEW reference, we first check whether the field
      is also an outer reference, and mark it appropriately before returning.
      97c105cc
  5. 23 Jan, 2008 1 commit
  6. 11 Jan, 2008 1 commit
    • evgen@moonbone.local's avatar
      Bug#29477: Not all fields of the target table were checked to have a default · baaf300d
      evgen@moonbone.local authored
      value when inserting into a view.
      
      The mysql_prepare_insert function checks all fields of the target table that
      directly or indirectly (through a view) are specified in the INSERT
      statement to have a default value. This check can be skipped if the INSERT
      statement doesn't mention any insert fields. In case of a view this allows
      fields that aren't mentioned in the view to bypass the check.
      
      Now fields of the target table are always checked to have a default value
      when insert goes into a view.
      baaf300d
  7. 09 Jan, 2008 1 commit
  8. 10 Oct, 2007 1 commit
  9. 24 Sep, 2007 1 commit
  10. 28 Jul, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#30020: Insufficient check led to a wrong info provided by the · f18b2386
      evgen@moonbone.local authored
      information schema table.
      
      The get_schema_views_record() function fills records in the view table of
      the informations schema with data about given views. Among other info
      the is_updatable flag is set. But the check whether the view is updatable or
      not wasn't covering all cases thus sometimes providing wrong info.
      This might led to a user confusion.
      
      Now the get_schema_views_record function additionally calls to the 
      view->can_be_merge() function to find out whether the view can be updated or
      not.
      f18b2386
  11. 05 Jul, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #29392. · 4c02004d
      igor@olga.mysql.com authored
      This bug may manifest itself for select queries over a multi-table view
      that includes an ORDER BY clause in its definition. If the select list of 
      the query contains references to the same view column with different
      aliases the names of the columns in the result output will be nevertheless
      the same, coinciding with one of the alias.
      
      The bug happened because the method Item_ref::get_tmp_table_item that
      was inherited by the class Item_direct_view_ref ignored the fact that
      the name of the view column reference must be inherited by the fields
      of the temporary table that was created in order to get the result rows
      sorted.
      4c02004d
  12. 20 Jun, 2007 1 commit
    • 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
  13. 09 Jun, 2007 1 commit
  14. 06 Jun, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #28701: · 68e2efcc
      gkodinov/kgeorge@macbook.gmz authored
      Views don't have indexes. So they can't take index hints.
      Added a check and disabled the usage of hints for views.
      68e2efcc
  15. 05 Jun, 2007 1 commit
    • svoj@mysql.com/april.(none)'s avatar
      BUG#26976 - Missing table in merge not noted in related error msg + · bd8f81f4
      svoj@mysql.com/april.(none) authored
                  SHOW CREATE TABLE fails
      
      Underlying table names, that merge engine fails to open were not
      reported.
      
      With this fix CHECK TABLE issued against merge table reports all
      underlying table names that it fails to open. Other statements
      are unaffected, that is underlying table names are not included
      into error message.
      
      This fix doesn't solve SHOW CREATE TABLE issue.
      bd8f81f4
  16. 31 May, 2007 1 commit
    • 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
  17. 30 May, 2007 3 commits
  18. 24 May, 2007 1 commit
  19. 09 May, 2007 1 commit
  20. 20 Apr, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #27786: · 4c89a596
      gkodinov/kgeorge@magare.gmz authored
      When merging views into the enclosing statement
      the ORDER BY clause of the view is merged to the
      parent's ORDER BY clause.
      However when the VIEW is merged into an UNION
      branch the ORDER BY should be ignored. 
      Use of ORDER BY for individual SELECT statements
      implies nothing about the order in which the rows
      appear in the final result because UNION by default
      produces unordered set of rows.
      Fixed by ignoring the ORDER BY clause from the merge
      view when expanded in an UNION branch.
      4c89a596
  21. 12 Apr, 2007 1 commit
    • gshchepa/uchum@gshchepa.localdomain's avatar
      Bug#5507: TRUNCATE does not work with views. · 4b2aab14
      gshchepa/uchum@gshchepa.localdomain authored
      Support of views wasn't implemented for the TRUNCATE statement.
      Now TRUNCATE on views has the same semantics as DELETE FROM view:
      mysql_truncate() checks whether the table is a view and falls back
      to delete if so.
      In order to initialize properly the LEX::updatable for a view
      st_lex::can_use_merged() now allows usage of merged views for the
      TRUNCATE statement.
      4b2aab14
  22. 09 Mar, 2007 1 commit
  23. 06 Mar, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · b216d959
      malff/marcsql@weblab.(none) authored
      Bug 18914 (Calling certain SPs from triggers fail)
      Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
      Bug 21825 (Incorrect message error deleting records in a table with a
        trigger for inserting)
      Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
        error)
      Bug 25345 (Cursors from Functions)
      
      
      This fix resolves a long standing issue originally reported with bug 8407,
      which affect the behavior of Stored Procedures, Stored Functions and Trigger
      in many different ways, causing symptoms reported by all the bugs listed.
      In all cases, the root cause of the problem traces back to 8407 and how the
      server locks tables involved with sub statements.
      
      Prior to this fix, the implementation of stored routines would:
      - compute the transitive closure of all the tables referenced by a top level
      statement
      - open and lock all the tables involved
      - execute the top level statement
      "transitive closure of tables" means collecting:
      - all the tables,
      - all the stored functions,
      - all the views,
      - all the table triggers
      - all the stored procedures
      involved, and recursively inspect these objects definition to find more
      references to more objects, until the list of every object referenced does
      not grow any more.
      This mechanism is known as "pre-locking" tables before execution.
      The motivation for locking all the tables (possibly) used at once is to
      prevent dead locks.
      
      One problem with this approach is that, if the execution path the code
      really takes during runtime does not use a given table, and if the table is
      missing, the server would not execute the statement.
      This in particular has a major impact on triggers, since a missing table
      referenced by an update/delete trigger would prevent an insert trigger to run.
      
      Another problem is that stored routines might define SQL exception handlers
      to deal with missing tables, but the server implementation would never give
      user code a chance to execute this logic, since the routine is never
      executed when a missing table cause the pre-locking code to fail.
      
      With this fix, the internal implementation of the pre-locking code has been
      relaxed of some constraints, so that failure to open a table does not
      necessarily prevent execution of a stored routine.
      
      In particular, the pre-locking mechanism is now behaving as follows:
      
      1) the first step, to compute the transitive closure of all the tables
      possibly referenced by a statement, is unchanged.
      
      2) the next step, which is to open all the tables involved, only attempts
      to open the tables added by the pre-locking code, but silently fails without
      reporting any error or invoking any exception handler is the table is not
      present. This is achieved by trapping internal errors with
      Prelock_error_handler
      
      3) the locking step only locks tables that were successfully opened.
      
      4) when executing sub statements, the list of tables used by each statements
      is evaluated as before. The tables needed by the sub statement are expected
      to be already opened and locked. Statement referencing tables that were not
      opened in step 2) will fail to find the table in the open list, and only at
      this point will execution of the user code fail.
      
      5) when a runtime exception is raised at 4), the instruction continuation
      destination (the next instruction to execute in case of SQL continue
      handlers) is evaluated.
      This is achieved with sp_instr::exec_open_and_lock_tables()
      
      6) if a user exception handler is present in the stored routine, that
      handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
      trapped by stored routines. If no handler exists, then the runtime execution
      will fail as expected.
      
      With all these changes, a side effect is that view security is impacted, in
      two different ways.
      
      First, a view defined as "select stored_function()", where the stored
      function references a table that may not exist, is considered valid.
      The rationale is that, because the stored function might trap exceptions
      during execution and still return a valid result, there is no way to decide
      when the view is created if a missing table really cause the view to be invalid.
      
      Secondly, testing for existence of tables is now done later during
      execution. View security, which consist of trapping errors and return a
      generic ER_VIEW_INVALID (to prevent disclosing information) was only
      implemented at very specific phases covering *opening* tables, but not
      covering the runtime execution. Because of this existing limitation,
      errors that were previously trapped and converted into ER_VIEW_INVALID are
      not trapped, causing table names to be reported to the user.
      This change is exposing an existing problem, which is independent and will
      be resolved separately.
      b216d959
  24. 05 Mar, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #26560. · 08efa4e0
      igor@olga.mysql.com authored
      The flag alias_name_used was not set on for the outer references
      in subqueries. It resulted in replacement of any outer reference
      resolved against an alias for a full field name when the frm 
      representation of a view with a subquery was generated. 
      If the subquery and the outer query referenced the same table in
      their from lists this replacement effectively changed the meaning
      of the view and led to wrong results for selects from this view. 
      
      Modified several functions to ensure setting the right value of
      the alias_name_used flag for outer references resolved against
      aliases.
       
      08efa4e0
  25. 23 Feb, 2007 1 commit
  26. 16 Feb, 2007 1 commit
  27. 12 Feb, 2007 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#24532 (The return data type of IS TRUE is different from similar · 4e556b23
      malff/marcsql@weblab.(none) authored
        operations)
      
      Before this change, the boolean predicates:
      - X IS TRUE,
      - X IS NOT TRUE,
      - X IS FALSE,
      - X IS NOT FALSE
      were implemented by expanding the Item tree in the parser, by using a
      construct like:
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
      
      Each <value> was a constant integer, either 0 or 1.
      
      A bug in the implementation of the function IF(a, b, c), in
      Item_func_if::fix_length_and_dec(), would cause the following :
      
      When the arguments b and c are both unsigned, the result type of the
      function was signed, instead of unsigned.
      
      When the result of the if function is signed, space for the sign could be
      counted twice (in the max() expression for a signed argument, and in the
      total), causing the member max_length to be too high.
      
      An effect of this is that the final type of IF(x, int(1), int(1)) would be
      int(2) instead of int(1).
      
      With this fix, the problems found in Item_func_if::fix_length_and_dec()
      have been fixed.
      
      While it's semantically correct to represent 'X IS TRUE' with
      Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
      there are however more problems with this construct.
      
      a)
      Building the parse tree involves :
      - creating 5 Item instances (3 ints, 1 ifnull, 1 if),
      - creating each Item calls my_pthread_getspecific_ptr() once in the operator
        new(size), and a second time in the Item::Item() constructor, resulting
        in a total of 10 calls to get the current thread.
      Evaluating the expression involves evaluating up to 4 nodes at runtime.
      This representation could be greatly simplified and improved.
      
      b)
      Transforming the parse tree internally with if(ifnull(...)) is fine as long
      as this transformation is internal to the server implementation.
      With views however, the result of the parse tree is later exposed by the
      ::print() functions, and stored as part of the view definition.
      Doing this has long term consequences:
      
      1)
      The original semantic 'X IS TRUE' is lost, and replaced by the
      if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
      the original code.
      
      2)
      Should a future version of MySQL implement the SQL BOOLEAN data type for
      example, views created today using 'X IS NULL' can be exported using
      mysqldump, and imported again. Such views would be converted correctly and
      automatically to use a BOOLEAN column in the future version.
      With 'X IS TRUE' and the current implementations, views using these
      "boolean" predicates would not be converted during the export/import, and
      would use integer columns instead.
      The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
      does not preserve the 'X IS TRUE' semantic.
      
      With this fix, internal representation of 'X IS TRUE' booleans predicates
      has changed, so that:
      - dedicated Item classes are created for each predicate,
      - only 1 Item is created to represent 1 predicate
      - my_pthread_getspecific_ptr() is invoked 1 time instead of 10
      - SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
      
      Note that, because of the fix in Item_func_if, views created before this fix
      will:
      - correctly use a int(1) type instead of int(2) for boolean predicates,
      - incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
      since the original semantic (X IS TRUE) has been lost.
      - except for the syntax used in SHOW CREATE VIEW, these views will operate
      properly, no action is needed.
      
      Views created after this fix will operate correctly, and will preserve the
      original code semantic in SHOW CREATE VIEW.
      4e556b23
    • igor@olga.mysql.com's avatar
      Fixed bug #26209. · 4b1a1d9e
      igor@olga.mysql.com authored
      The function make_unireg_sortorder ignored the fact that any
      view field is represented by a 'ref' object.
      This could lead to wrong results for the queries containing
      both GROUP BY and ORDER BY clauses.
      4b1a1d9e
  28. 09 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#12122: The MERGE algorithm isn't applicable if the ORDER BY clause is · a2414463
      evgen@moonbone.local authored
      present.
      
      A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with
      the MERGE algorithm, even when no other part of the CREATE VIEW statement
      would require the view to be resolved using the TEMPTABLE algorithm.
      
      The check for presence of the ORDER BY clause in the underlying select is 
      removed from the st_lex::can_be_merged() function.
      The ORDER BY list of the underlying select is appended to the ORDER BY list 
      a2414463
  29. 07 Feb, 2007 2 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #25931. · 8d4027fd
      igor@olga.mysql.com authored
      View check option clauses were ignored for updates of multi-table
      views when the updates could not be performed on fly and the rows
      to update had to be put into temporary tables first.
      8d4027fd
    • igor@olga.mysql.com's avatar
      Fixed bug #26124: SELECT from a view wrapper over a table · 5ed805bf
      igor@olga.mysql.com authored
      with a column of the DATETIME type could return a wrong 
      result set if the WHERE clause included a BETWEEN condition
      on the column.
      Fixed the method Item_func_between::fix_length_and_dec
      where the aggregation type for BETWEEN predicates calculated
      incorrectly if the first argument was a view column of the
      DATETIME type.
      5ed805bf
  30. 04 Feb, 2007 1 commit
  31. 18 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25580: incorrect stored representations of views in cases · c1927e9a
      igor@olga.mysql.com authored
      when they contain the '!' operator.
      Added an implementation for the method Item_func_not::print. 
      The method encloses any NOT expression into extra parentheses to avoid
      incorrect stored representations of views that use the '!' operators.
      Without this change when a view was created that contained
      the expression !0*5  its stored representation contained not this
      expression but rather the expression not(0)*5 . 
      The operator '!' is of a higher precedence than '*', while NOT is 
      of a lower precedence than '*'. That's why the expression !0*5 
      is interpreted as not(0)*5, while the expression not(0)*5 is interpreted
      as not((0)*5) unless sql_mode is set to HIGH_NOT_PRECEDENCE.
      Now we translate !0*5 into (not(0))*5. 
      c1927e9a
  32. 02 Jan, 2007 1 commit
  33. 19 Dec, 2006 1 commit
  34. 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
  35. 23 Oct, 2006 1 commit
  36. 17 Oct, 2006 1 commit