An error occurred fetching the project authors.
  1. 04 Feb, 2007 1 commit
    • unknown's avatar
      BUG#25897: Some queries are no longer possible after a CREATE VIEW · 86b715a7
      unknown authored
                 fails
      
      The bug was introduced with the push of the fix for bug#20953: after
      the error on view creation we never reset the error state, so some
      valid statements would give the same error after that.
      
      The solution is to properly reset the error state.
      
      
      mysql-test/r/view.result:
        Add result for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      mysql-test/t/view.test:
        Add test case for bug#25897: Some queries are no longer possible after
        a CREATE VIEW fails.
      sql/sql_lex.cc:
        Add st_parsing_options::reset() method, call it from lex_start().
      sql/sql_lex.h:
        Add st_parsing_options::reset() method, call it from constructor.
      86b715a7
  2. 02 Jan, 2007 1 commit
    • unknown's avatar
      view.result: · 2e99ee90
      unknown authored
        Temporary work around for bug#25359
      
      
      mysql-test/r/view.result:
        Temporary work around for bug#25359
      2e99ee90
  3. 19 Dec, 2006 1 commit
    • unknown's avatar
      Fix for BUG#24293: '\Z' token is not handled correctly in views. · b66ab7f8
      unknown authored
      If SELECT-part of CREATE VIEW statement contains '\Z',
      it is not handled correctly.
      
      The problem was in String::print().
      Symbol with code 032 (26) is replaced with '\z',
      which is not supported by the lexer.
      
      The fix is to replace the symbol with '\Z'.
      
      
      mysql-test/r/view.result:
        Update result file.
      mysql-test/t/view.test:
        Add test case for BUG#24293.
      sql/sql_string.cc:
        We should replace 032 with \Z, since lexer does not understand \z.
      b66ab7f8
  4. 27 Oct, 2006 1 commit
    • unknown's avatar
      BUG#22584: last_insert_id not updated after inserting a record through · 532735e6
      unknown 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.
      
      
      mysql-test/r/view.result:
        Add result for bug#22584: last_insert_id not updated after inserting
        a record through a updatable view.
      mysql-test/t/view.test:
        Add test case for bug#22584: last_insert_id not updated after inserting
        a record through a updatable view.
      sql/sql_parse.cc:
        When we have inserted into a view, and AUTO_INCREMENT column is not
        accessed from this view, instead of setting LAST_INSERT_ID to zero set
        it to the value it had before this statement was executed.
      532735e6
  5. 23 Oct, 2006 1 commit
  6. 17 Oct, 2006 1 commit
    • unknown's avatar
      Fix previous bad patch for Bug#14262. · 48dfeb4d
      unknown authored
      Remove table engine qualification where it's unnecessary.
      
      
      mysql-test/r/view.result:
        Remove requirement for innodb where not needed.  (Running this test alone
        raised warnings that it was using myisam.)
      mysql-test/t/view.test:
        Remove requirement for innodb where not needed.  (Running this test alone
        raised warnings that it was using myisam.)
      sql/sql_parse.cc:
        Fix previous bad re-patch.
      sql/sql_view.cc:
        Fix previous bad re-patch.
      48dfeb4d
  7. 12 Oct, 2006 1 commit
    • unknown's avatar
      BUG#20953: create proc with a create view that uses local vars/params · 6d1fdc73
      unknown 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.
      
      
      mysql-test/r/sp-error.result:
        Add result for bug#20953: create proc with a create view that uses
        local vars/params should fail to create.
      mysql-test/r/view.result:
        Update results.
      mysql-test/t/sp-error.test:
        Add test case for bug#20953: create proc with a create view that uses
        local vars/params should fail to create.
      mysql-test/t/view.test:
        Add second test for variable in a view.
        Remove SP variable in a view test, as it tests wrong behaviour.
        Add test for derived table in a view.
      sql/sql_lex.cc:
        Remove LEX::variables_used.
      sql/sql_lex.h:
        Remove LEX::variables_used and add st_parsing_options structure and
        LEX::parsing_options member.
      sql/sql_view.cc:
        Move some error checking to sql/sql_yacc.yy.
      sql/sql_yacc.yy:
        Check for disallowed syntax in a CREATE VIEW at parse time to rise a
        error when it is used inside CREATE PROCEDURE and CREATE FUNCTION, as
        well as by itself.
      6d1fdc73
  8. 10 Oct, 2006 2 commits
    • unknown's avatar
      Fix after manial merge. · c942d5bf
      unknown authored
      c942d5bf
    • unknown's avatar
      Bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. · 469ff92d
      unknown 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.
      
      
      mysql-test/r/view.result:
        Add result for bug#19111: TRIGGERs selecting from a VIEW on the
        firing base table fail.
      mysql-test/t/view.test:
        Add test case for bug#19111: TRIGGERs selecting from a VIEW on the
        firing base table fail.
      sql/sql_base.cc:
        In unique_table() do not check tables that are used in a stored
        function or a trigger ('prelocking_placeholder' is set).  If such
        function or a trigger will attempt to modify a table, the error will
        be given, however select is allowed there.
      469ff92d
  9. 29 Sep, 2006 1 commit
    • unknown's avatar
      bug #16813 (WITH CHECK OPTION fails with UPDATE) · 5389cc16
      unknown 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. 
      
      
      mysql-test/r/view.result:
        result fixed
      mysql-test/t/view.test:
        testcase
      sql/table.cc:
        now we use the copy of the CHECK OPTION condition to construct
        the select's condition
      5389cc16
  10. 28 Sep, 2006 1 commit
    • unknown's avatar
      Fixed bug#5505: Wrong error message on INSERT into a view · d332c37c
      unknown 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.
      
      
      sql/sql_base.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        The update_non_unique_table_error() function now issues proper
        error for an INSERT.
      sql/sql_insert.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Issue the ER_NON_INSERTABLE_TABLE error instead of the 
        ER_NON_UPDATABLE_TABLE on insert into a view.
      sql/sql_view.cc:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Issue the ER_NON_INSERTABLE_TABLE error instead of the
        ER_NON_UPDATABLE_TABLE on insert into a view.
      mysql-test/r/view.result:
        Added the test case for bug#5505: Wrong error message on INSERT into a view
        Corrected a few test cases after fixing bug#5505
      mysql-test/t/view.test:
        Added the test case for bug#5505: Wrong error message on INSERT into a view
        Corrected a few test cases after fixing bug#5505
      sql/share/errmsg.txt:
        Fixed bug#5505: Wrong error message on INSERT into a view
        Added the ER_NON_INSERTABLE_TABLE error definition.
      d332c37c
  11. 25 Sep, 2006 1 commit
    • unknown's avatar
      Fixed bug #21646. · f0bd502a
      unknown 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.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #21646.
      mysql-test/t/view.test:
        Added a test case for bug #21646.
      sql/mysql_priv.h:
        Fixed bug #21646.
        Added a new parsing state 'IN_ON', true when
        the parser is in an ON expression of a join.
      sql/sql_lex.cc:
        Fixed bug #21646.
        Presence of a subquery in the ON expression of a join 
        should not block merging the view that contains this join.
      sql/sql_yacc.yy:
        Fixed bug #21646.
        Added a new parsing state 'IN_ON', true when
        the parser is in an ON expression of a join.
      f0bd502a
  12. 18 Sep, 2006 1 commit
  13. 14 Sep, 2006 1 commit
    • unknown's avatar
      type_date.result: · 0847bd9c
      unknown 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
      
      
      mysql-test/t/view.test:
        Corrected a test case after removal of fix for bug#16377
      mysql-test/t/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
      mysql-test/t/func_time.test:
        Corrected a test case after removal of fix for bug#16377
      mysql-test/r/view.result:
        Corrected a test case after removal of fix for bug#16377
      mysql-test/r/type_date.result:
        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
      mysql-test/r/query_cache.result:
        Corrected a test case after removal of fix for bug#16377
      mysql-test/r/func_time.result:
        Corrected a test case after removal of fix for bug#16377
      sql/item_cmpfunc.cc:
        Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
      0847bd9c
  14. 06 Sep, 2006 1 commit
    • unknown's avatar
      Fixed bug #5500: EXPLAIN returned a wrong select_type for queries using views. · 22c3e7b4
      unknown authored
      Select_type in the EXPLAIN output for the query SELECT * FROM t1 was
      'SIMPLE', while for the query SELECT * FROM v1, where the view v1
      was defined as SELECT * FROM t1, the EXPLAIN output contained 'PRIMARY'
      for the select_type column.
       
      
      
      mysql-test/r/group_by.result:
        Adjusted results after the fix for bug #5500.
      mysql-test/r/information_schema.result:
        Adjusted results after the fix for bug #5500.
      mysql-test/r/olap.result:
        Adjusted results after the fix for bug #5500.
      mysql-test/r/range.result:
        Adjusted results after the fix for bug #5500.
      mysql-test/r/view.result:
        Added a test case for bug #5500.
        Adjusted other results.
      mysql-test/r/view_grant.result:
        Adjusted results after the fix for bug #5500.
      mysql-test/t/view.test:
        Added a test case for bug #5500.
      22c3e7b4
  15. 29 Aug, 2006 2 commits
    • unknown's avatar
      Post-merge fixes. · 8f0b5afa
      unknown authored
      mysql-test/r/view.result:
        A post-merge fix.
      mysql-test/t/grant.test:
        A post-merge fix.
      mysql-test/t/view.test:
        A post-merge fix.
      8f0b5afa
    • unknown's avatar
      BUG#17591: Updatable view not possible with trigger or stored function · 7a5a2544
      unknown authored
      When a view was used inside a trigger or a function, lock type for
      tables used in a view was always set to READ (thus making the view
      non-updatable), even if we were trying to update the view.
      
      The solution is to set lock type properly.
      
      
      mysql-test/r/view.result:
        Add result for bug#17591: Updatable view not possible with trigger
        or stored function.
      mysql-test/t/view.test:
        Add test case for bug#17591: Updatable view not possible with trigger
        or stored function.
      sql/sql_view.cc:
        Move the code that sets requested lock type before the point where
        we exit from mysql_make_view() when we process a placeholder for
        prelocked table.
      7a5a2544
  16. 24 Aug, 2006 1 commit
    • unknown's avatar
      Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause · 21e6836b
      unknown authored
          
      User name (host name) has limit on length. The server code relies on these
      limits when storing the names. The problem was that sometimes these limits
      were not checked properly, so that could lead to buffer overflow.
        
      The fix is to check length of user/host name in parser and if string is too
      long, throw an error.
      
      
      mysql-test/r/grant.result:
        Updated result file.
      mysql-test/r/sp.result:
        Updated result file.
      mysql-test/r/trigger.result:
        Updated result file.
      mysql-test/r/view.result:
        Updated result file.
      mysql-test/t/grant.test:
        Added test for BUG#16899.
      mysql-test/t/sp.test:
        Added test for BUG#16899.
      mysql-test/t/trigger.test:
        Added test for BUG#16899.
      mysql-test/t/view.test:
        Added test for BUG#16899.
      sql/mysql_priv.h:
        Added prototype for new function.
      sql/sql_acl.cc:
        Remove outdated checks.
      sql/sql_parse.cc:
        Add a new function for checking string length.
      sql/share/errmsg.txt:
        Added new resources.
      sql/sql_yacc.yy:
        Check length of user/host name.
      21e6836b
  17. 23 Aug, 2006 2 commits
    • unknown's avatar
      view.result, view.test: · d0394c70
      unknown authored
        Corrected test case for the bug#21261
      sql_parse.cc:
        Corrected fix for bug#21261
      
      
      mysql-test/t/view.test:
        Corrected test case for the bug#21261
      mysql-test/r/view.result:
        Corrected test case for the bug#21261
      sql/sql_parse.cc:
        Corrected fix for bug#21261
      d0394c70
    • unknown's avatar
      Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause · f96ee72f
      unknown authored
        
      User name (host name) has limit on length. The server code relies on these
      limits when storing the names. The problem was that sometimes these limits
      were not checked properly, so that could lead to buffer overflow.
      
      The fix is to check length of user/host name in parser and if string is too
      long, throw an error.
      
      
      mysql-test/r/grant.result:
        Updated result file.
      mysql-test/r/sp.result:
        Updated result file.
      mysql-test/r/trigger.result:
        Updated result file.
      mysql-test/r/view.result:
        Updated result file.
      mysql-test/t/grant.test:
        Added test for BUG#16899.
      mysql-test/t/sp.test:
        Added test for BUG#16899.
      mysql-test/t/trigger.test:
        Added test for BUG#16899.
      mysql-test/t/view.test:
        Added test for BUG#16899.
      sql/mysql_priv.h:
        Added prototype for new function.
      sql/share/errmsg.txt:
        Added new resources.
      sql/sql_acl.cc:
        Remove outdated checks.
      sql/sql_parse.cc:
        Add a new function for checking string length.
      sql/sql_yacc.yy:
        Check length of user/host name.
      f96ee72f
  18. 17 Aug, 2006 1 commit
    • unknown's avatar
      ndb_condition_pushdown.result: · 1cbebc6e
      unknown authored
        Corrected test case result after fix for bug#18165
      view.result, view.test:
        Corrected test case for bug#21261
      
      
      mysql-test/t/view.test:
        Corrected test case for bug#21261
      mysql-test/r/view.result:
        Corrected test case for bug#21261
      mysql-test/r/ndb_condition_pushdown.result:
        Corrected test case result after fix for bug#18165
      1cbebc6e
  19. 15 Aug, 2006 2 commits
    • unknown's avatar
      Fixed bug#21261: Wrong access rights was required for an insert into a view · a23d1792
      unknown 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.
      
      
      mysql-test/t/view.test:
        Added a test case for bug#21261: Wrong access rights was required for an insert into a view
      mysql-test/r/view.result:
        Added a test case for bug#21261: Wrong access rights was required for an insert into a view
      sql/sql_update.cc:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        Modified to use updated setup_tables_and_check_access() function.
      sql/sql_select.cc:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        Modified to use updated setup_tables_and_check_access() function.
      sql/sql_load.cc:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        Modified to use updated setup_tables_and_check_access() function.
      sql/sql_insert.cc:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        Modified to use updated setup_tables_and_check_access() function.
      sql/sql_delete.cc:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        Modified to use updated setup_tables_and_check_access() function.
      sql/sql_base.cc:
        Fixed bug#21261: Wrong access rights was required 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.
      sql/mysql_priv.h:
        Fixed bug#21261: Wrong access rights was required for an insert into a view
        The setup_tables_and_check_access() function now accepts two want_access
        parameters.
      a23d1792
    • unknown's avatar
      Fixed bug#15950: NOW() optimized away in VIEWs · c2ef98ad
      unknown 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.
      
      
      mysql-test/t/view.test:
        Added a test case for bug#15950: NOW() optimized away in VIEWs
      mysql-test/r/view.result:
        Added a test case for bug#15950: NOW() optimized away in VIEWs
      sql/item_cmpfunc.cc:
        Fixed bug#15950: NOW() optimized away in VIEWs
        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.
      c2ef98ad
  20. 02 Aug, 2006 1 commit
    • unknown's avatar
      BUG#14770 - LOAD DATA INFILE doesn't respect default values for · a1bd0bd1
      unknown 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.
      
      
      mysql-test/r/auto_increment.result:
        Fixed confusing warning.
      mysql-test/r/create.result:
        Fixed confusing warning.
      mysql-test/r/insert.result:
        Fixed confusing warning.
      mysql-test/r/insert_select.result:
        Fixed confusing warning.
      mysql-test/r/key.result:
        Fixed confusing warning.
      mysql-test/r/null.result:
        Fixed confusing warning.
      mysql-test/r/null_key.result:
        Fixed confusing warning.
      mysql-test/r/ps_2myisam.result:
        Fixed confusing warning.
      mysql-test/r/ps_3innodb.result:
        Fixed confusing warning.
      mysql-test/r/ps_4heap.result:
        Fixed confusing warning.
      mysql-test/r/ps_5merge.result:
        Fixed confusing warning.
      mysql-test/r/ps_6bdb.result:
        Fixed confusing warning.
      mysql-test/r/strict.result:
        Fixed confusing warning.
      mysql-test/r/view.result:
        Fixed confusing warning.
      mysql-test/r/warnings.result:
        Fixed confusing warning.
      sql/share/errmsg.txt:
        Fixed confusing warning.
      a1bd0bd1
  21. 31 Jul, 2006 2 commits
    • unknown's avatar
      Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE · b74cb623
      unknown authored
       
      made DROP VIEW to continue on error and report an aggregated error 
       at its end. This makes it similar to DROP TABLE.
      
      
      mysql-test/r/view.result:
        Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
         - test case
         - changed error message
      mysql-test/t/view.test:
        Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
         - test case
      sql/sql_view.cc:
        Bug #11551: Asymmetric + undocumented behaviour of DROP VIEW and DROP TABLE
         - made DROP VIEW to continue on error and report an aggregated error
      b74cb623
    • unknown's avatar
      Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM · c8673b09
      unknown authored
        When executing ALTER TABLE all the attributes of the view were overwritten.
        This is contrary to the user's expectations.
        So some of the view attributes are preserved now : namely security and 
        algorithm. This means that if they are not specified in ALTER VIEW
        their values are preserved from CREATE VIEW instead of being defaulted.
      
      
      mysql-test/r/view.result:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - test suite
      mysql-test/t/view.test:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - test suite
      sql/sql_lex.h:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - must make create_view_suid a tristate : on/off/unspecified
      sql/sql_view.cc:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - open the view to get it's attributes and put then as defaults 
           for ALTER VIEW
      sql/sql_yacc.yy:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - must make create_view_suid a tristate : on/off/unspecified
      sql/table.h:
        Bug #21080: ALTER VIEW makes user restate SQL SECURITY mode, and ALGORITHM
         - must make create_view_suid a tristate : on/off/unspecified
      c8673b09
  22. 25 Jul, 2006 1 commit
    • unknown's avatar
      Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called · 1b3cdb60
      unknown 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.
      
      
      mysql-test/r/view.result:
        Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
         - test suite
      mysql-test/t/view.test:
        Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
         - test suite
      sql/item_strfunc.h:
        Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
         - obvious typo fixed
      sql/sql_base.cc:
        Bug #21086: server crashes when VIEW defined with a SELECT with COLLATE clause is called
         - must access field information through the filed_for_view_update() function to retrieve
           correctly the field info even for "update-friendly" non-Item_field items.
      1b3cdb60
  23. 20 Jul, 2006 1 commit
    • unknown's avatar
      Bug#6147: Traditional: Assigning a string to a numeric column has unexpected results · 03d411b1
      unknown authored
      The problem was that when converting a string to an exact number,
      rounding didn't work, because conversion didn't understand
      approximate numbers notation.
      Fix: a new function for string-to-number conversion was implemented,
      which is aware of approxinate number notation (with decimal point
      and exponent, e.g. -19.55e-1)
      
      
      include/m_ctype.h:
        Adding new function into MY_CHARSET_HANDLER
        Adding prototypes for 8bit and ucs2 functions.
      mysql-test/r/loaddata.result:
        Fixing results
      mysql-test/r/ps_2myisam.result:
        Fixing results
      mysql-test/r/ps_3innodb.result:
        Fixing results
      mysql-test/r/ps_4heap.result:
        Fixing results
      mysql-test/r/ps_5merge.result:
        Fixing results
      mysql-test/r/ps_6bdb.result:
        Fixing results
      mysql-test/r/rpl_rewrite_db.result:
        Fixing results
      mysql-test/r/select.result:
        Fixing results
      mysql-test/r/sp-vars.result:
        Fixing results
      mysql-test/r/strict.result:
        Fixing results
      mysql-test/r/view.result:
        Fixing results
      mysql-test/r/warnings.result:
        Fixing results
      mysql-test/t/strict.test:
        Fixing results
      sql/field.cc:
        Using new function
      strings/ctype-big5.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-bin.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-cp932.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-euc_kr.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-eucjpms.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-gb2312.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-gbk.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-latin1.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-simple.c:
        Implementing my_strntoull10_8bit
        Adding new function into MY_CHARSET_HANDLER
      strings/ctype-sjis.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-tis620.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-ucs2.c:
        Implementing UCS2 wrapper for 8bit version
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-ujis.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      strings/ctype-utf8.c:
        Adding new function into the MY_CHARSET_HANDLER structure
      mysql-test/r/round.result:
        New BitKeeper file ``mysql-test/r/round.result''
      mysql-test/t/round.test:
        New BitKeeper file ``mysql-test/t/round.test''
      03d411b1
  24. 19 Jul, 2006 1 commit
  25. 14 Jul, 2006 1 commit
    • unknown's avatar
      Fixed bug #19714. · 1e442594
      unknown 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.
       
      
      
      mysql-test/r/analyse.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/bigint.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/create.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/olap.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_2myisam.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_3innodb.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_4heap.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_5merge.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_6bdb.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/ps_7ndb.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/sp.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/subselect.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/type_ranges.result:
        Adjusted the results after having fixed bug #19714.
      mysql-test/r/view.result:
        Added a test case for bug #19714.
      mysql-test/t/view.test:
        Added a test case for bug #19714.
      1e442594
  26. 06 Jul, 2006 1 commit
  27. 04 Jul, 2006 1 commit
    • unknown's avatar
      Bug #16110: insert permitted into view col w/o default value · e08ff115
      unknown 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.
      
      
      mysql-test/r/view.result:
        Bug #16110: insert permitted into view col w/o default value
          * test case
      mysql-test/t/view.test:
        Bug #16110: insert permitted into view col w/o default value
          * test case
      sql/sql_insert.cc:
        Bug #16110: insert permitted into view col w/o default value
          * avoid setting the "field used" flag for fields when checking view columns 
            for updatability.
          * a missing DBUG_RETURN added.
      e08ff115
  28. 27 Jun, 2006 1 commit
    • unknown's avatar
      Bug#17203: "sql_no_cache sql_cache" in views created from prepared statement · 90cb4c03
      unknown authored
      The problem was that we restored SQL_CACHE, SQL_NO_CACHE flags in SELECT
      statement from internal structures based on value set later at runtime, not
      the original value set by the user.
      
      The solution is to remember that original value.
      
      
      mysql-test/r/auto_increment.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/func_compress.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/func_math.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/func_system.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/func_time.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/information_schema.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/query_cache.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/rpl_get_lock.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/rpl_master_pos_wait.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/show_check.result:
        Add result for bug#17203.
      mysql-test/r/subselect.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/type_blob.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/variables.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/r/view.result:
        Update result to not report SQL_NO_CACHE if it wasn't there at first place.
      mysql-test/t/show_check.test:
        Add test case for bug#17203.
      sql/sql_lex.cc:
        Reset SELECT_LEX::sql_cache together with SELECT_LEX::options.
      sql/sql_lex.h:
        Add SELECT_LEX::sql_cache field to store original user setting.
      sql/sql_select.cc:
        Output SQL_CACHE and SQL_NO_CACHE depending on stored original user setting.
      sql/sql_yacc.yy:
        Make effect of SQL_CACHE and SQL_NO_CACHE mutually exclusive.  Ignore
        SQL_CACHE if SQL_NO_CACHE was used.  Remember what was set by the user.
        Reset SELECT_LEX::sql_cache together with SELECT_LEX::options.
      90cb4c03
  29. 01 Jun, 2006 1 commit
  30. 22 May, 2006 1 commit
    • unknown's avatar
      Post-review fixes for bug #19089 · 321708d3
      unknown authored
      mysql-test/r/view.result:
        Post-review fixes.
      sql/field.cc:
        Post-review fixes.
      sql/field.h:
        Post-review fixes.
      sql/sql_select.cc:
        Post-review fixes.
      321708d3
  31. 21 May, 2006 1 commit
    • unknown's avatar
      Fixed bug #19089. · db5d1974
      unknown 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.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #19089.
      mysql-test/t/view.test:
        Added a test case for bug #19089.
      sql/field.cc:
        Fixed bug ##19089.
        Added field dflt_field to the class Field.
        This field is set for temp table fields that inherits
        default values of items from which they are created.
      sql/field.h:
        Fixed bug ##19089.
        Added field dflt_field to the class Field.
        This field is set for temp table fields that inherits
        default values of items from which they are created.
      sql/sql_select.cc:
        Fixed bug #19089.
        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.
        The code was modified to ensure inheritance of default values for
        materialized views.
      db5d1974
  32. 17 May, 2006 2 commits
    • unknown's avatar
      Fixed bug#19077: A nested materialized derived table is used before being populated. · 1c6beaee
      unknown 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. 
      
      
      mysql-test/t/view.test:
        Added test case for bug#19077: A nested materialized derived table is used before being populated.
      mysql-test/t/subselect.test:
        Added test case for bug#19077: A nested materialized derived table is used before being populated.
      mysql-test/r/view.result:
        Added test case for bug#19077: A nested materialized derived table is used before being populated.
      mysql-test/r/subselect.result:
        Added test case for bug#19077: A nested materialized derived table is used before being populated.
      sql/item_subselect.cc:
        Fixed bug#19077: A nested materialized derived table is used before being populated.
        The Item_subselect class constructor sets new with_subselect flag to 1.
      sql/item_func.cc:
        Fixed bug#19077: A nested materialized derived table is used before being populated.
        
        The Item_func::fix_fields() sets new with_subselect flag from with_subselect flags of its arguments.
      sql/item_cmpfunc.cc:
        Fixed bug#19077: A nested materialized derived table is used before being populated.
        The convert_constant_item() function now doesn't convert a constant item
        with the with_subselect flag set.
        The Item_cond::fix_fields() sets new with_subselect flag from with_subselect flags of its arguments.
      sql/item.cc:
        Fixed bug#19077: A nested materialized derived table is used before being populated.
        Set new with_subselect flag to default value - 0 in the Item constructor.
      sql/item.h:
        Fixed bug#19077: A nested materialized derived table is used before being populated.
        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.
      1c6beaee
    • unknown's avatar
      Fixed bug #19573. · f1efd088
      unknown 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.
      
      
      mysql-test/r/having.result:
        Adjusted results after fixing bug #19573.
      mysql-test/r/view.result:
        Added a test case for bug #19573.
      mysql-test/t/view.test:
        Added a test case for bug #19573.
      f1efd088
  33. 13 May, 2006 1 commit
    • unknown's avatar
      Fixed bug #19490. The bug that caused server crash manifested · 7bb4f778
      unknown 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.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #19490.
      mysql-test/t/view.test:
        Added a test case for bug #19490.
      sql/item_timefunc.cc:
        Fixed bug #19490. The bug that caused server crash manifested
        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.
        The code of Item_date_add_interval::eq was corrected.
      7bb4f778
  34. 11 May, 2006 1 commit
    • unknown's avatar
      BUG#7549: Missing error message for invalid view selection with subquery. · aeaaa456
      unknown 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. 
      
      
      mysql-test/r/subselect.result:
        test case
      mysql-test/r/view.result:
        chnaged explain due to column being resolved
      mysql-test/t/subselect.test:
        test case
      sql/item_subselect.cc:
        overloaded fix_fields to fix the left_expr in prepare_view_mode
      sql/item_subselect.h:
        fix_fields overloaded so it can prepare left_expr
      aeaaa456