An error occurred fetching the project authors.
  1. 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
  2. 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
  3. 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
  4. 30 Nov, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      A test case for BUG#26676: VIEW using old table schema in a session. · a1666e06
      anozdrin/alik@ibm. authored
      The following clarification should be made in The Manual:
      
      Standard SQL is quite clear that, if new columns are added
      to a table after a view on that table is created with
      "select *", the new columns will not become part of the view.
      In all cases, the view definition (view structure) is frozen
      at CREATE time, so changes to the underlying tables do not
      affect the view structure.
      a1666e06
  5. 10 Oct, 2007 2 commits
  6. 26 Sep, 2007 1 commit
  7. 24 Sep, 2007 2 commits
  8. 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
  9. 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
  10. 28 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
  11. 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
  12. 09 Jun, 2007 1 commit
  13. 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
  14. 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
  15. 31 May, 2007 2 commits
    • 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
    • igor@olga.mysql.com's avatar
      Post merge fix. · 4fb062de
      igor@olga.mysql.com authored
      4fb062de
  16. 30 May, 2007 3 commits
  17. 29 May, 2007 1 commit
  18. 27 May, 2007 1 commit
  19. 24 May, 2007 1 commit
  20. 09 May, 2007 1 commit
  21. 04 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      bug #27531: 5.1 part of the fix: · 306371a8
      gkodinov/kgeorge@magare.gmz authored
       - added join cache indication in EXPLAIN (Extra column).
       - prefer filesort over full scan over 
         index for ORDER BY (because it's faster).
       - when switching from REF to RANGE because
         RANGE uses longer key turn off sort on
         the head table only as the resulting 
         RANGE access is a candidate for join cache
         and we don't want to disable it by sorting
         on the first table only. 
      306371a8
  22. 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
  23. 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
  24. 23 Mar, 2007 1 commit
  25. 22 Mar, 2007 1 commit
  26. 09 Mar, 2007 4 commits
    • kroki/tomash@moonlight.home's avatar
      Resolve one shift/reduce conflict introduced with the push of the fix · 8ff2d861
      kroki/tomash@moonlight.home authored
      for bug#16425: Events: no DEFINER clause.  The problem was that there
      were two rules
      
        ALTER view_algorithm_opt definer ... VIEW ...
        ALTER definer EVENT ...
      
      so when there was 'ALTER definer' in the input it was unclear if empty
      view_algorithm_opt should be executed or not.
      
      We solve this by introducing three distinct rules
      
        ALTER view_algorithm definer ... VIEW ...
        ALTER definer ... VIEW ...
        ALTER definer EVENT ...
      
      that remove the ambiguity.
      8ff2d861
    • kroki/tomash@moonlight.home's avatar
      BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked · c19affef
      kroki/tomash@moonlight.home authored
      The problem was that some facilities (like CONVERT_TZ() function or
      server HELP statement) may require implicit access to some tables in
      'mysql' database.  This access was done by ordinary means of adding
      such tables to the list of tables the query is going to open.
      However, if we issued LOCK TABLES before that, we would get "table
      was not locked" error trying to open such implicit tables.
      
      The solution is to treat certain tables as MySQL system tables, like
      we already do for mysql.proc.  Such tables may be opened for reading
      at any moment regardless of any locks in effect.  The cost of this is
      that system table may be locked for writing only together with other
      system tables, it is disallowed to lock system tables for writing and
      have any other lock on any other table.
      
      After this patch the following tables are treated as MySQL system
      tables:
        mysql.help_category
        mysql.help_keyword
        mysql.help_relation
        mysql.help_topic
        mysql.proc (it already was)
        mysql.time_zone
        mysql.time_zone_leap_second
        mysql.time_zone_name
        mysql.time_zone_transition
        mysql.time_zone_transition_type
      
      These tables are now opened with open_system_tables_for_read() and
      closed with close_system_tables(), or one table may be opened with
      open_system_table_for_update() and closed with close_thread_tables()
      (the latter is used for mysql.proc table, which is updated as part of
      normal MySQL server operation).  These functions may be used when
      some tables were opened and locked already.
      
      NOTE: online update of time zone tables is not possible during
      replication, because there's no time zone cache flush neither on LOCK
      TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
      data from cache, while on slave updated data will be loaded from the
      time zone tables.
      c19affef
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      aftermerge fix · 4ab2b8d7
      holyfoot/hf@mysql.com/hfmain.(none) authored
      4ab2b8d7
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      aftermerge fix · 4752db40
      holyfoot/hf@mysql.com/hfmain.(none) authored
      4752db40
  27. 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
  28. 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
  29. 23 Feb, 2007 1 commit
  30. 16 Feb, 2007 2 commits
  31. 14 Feb, 2007 1 commit