1. 07 Mar, 2007 9 commits
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/50 · 30c1622e
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      30c1622e
    • unknown's avatar
      5501a291
    • unknown's avatar
      A fix for the windows build (harmless warning). · 4d6e16f2
      unknown authored
      
      sql/sql_lex.cc:
        A fix for the windows build.
      4d6e16f2
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 7f69b747
      unknown authored
      into  bodhi.local:/opt/local/work/mysql-5.0-26750
      
      
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_class.h:
        Manual merge.
      7f69b747
    • unknown's avatar
      A fix for Bug#26750 "valgrind leak in sp_head" (and post-review · 053c6c01
      unknown authored
      fixes).
      
      The legend: on a replication slave, in case a trigger creation
      was filtered out because of application of replicate-do-table/
      replicate-ignore-table rule, the parsed definition of a trigger was not 
      cleaned up properly. LEX::sphead member was left around and leaked 
      memory. Until the actual implementation of support of 
      replicate-ignore-table rules for triggers by the patch for Bug 24478 it 
      was never the case that "case SQLCOM_CREATE_TRIGGER"
      was not executed once a trigger was parsed,
      so the deletion of lex->sphead there worked and the memory did not leak.
      
      The fix: 
      
      The real cause of the bug is that there is no 1 or 2 places where
      we can clean up the main LEX after parse. And the reason we 
      can not have just one or two places where we clean up the LEX is
      asymmetric behaviour of MYSQLparse in case of success or error. 
      
      One of the root causes of this behaviour is the code in Item::Item()
      constructor. There, a newly created item adds itself to THD::free_list
      - a single-linked list of Items used in a statement. Yuck. This code
      is unaware that we may have more than one statement active at a time,
      and always assumes that the free_list of the current statement is
      located in THD::free_list. One day we need to be able to explicitly
      allocate an item in a given Query_arena.
      Thus, when parsing a definition of a stored procedure, like
      CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
      we actually need to reset THD::mem_root, THD::free_list and THD::lex
      to parse the nested procedure statement (SELECT *).
      The actual reset and restore is implemented in semantic actions
      attached to sp_proc_stmt grammar rule.
      The problem is that in case of a parsing error inside a nested statement
      Bison generated parser would abort immediately, without executing the
      restore part of the semantic action. This would leave THD in an 
      in-the-middle-of-parsing state.
      This is why we couldn't have had a single place where we clean up the LEX
      after MYSQLparse - in case of an error we needed to do a clean up
      immediately, in case of success a clean up could have been delayed.
      This left the door open for a memory leak.
      
      One of the following possibilities were considered when working on a fix:
      - patch the replication logic to do the clean up. Rejected
      as breaks module borders, replication code should not need to know the
      gory details of clean up procedure after CREATE TRIGGER.
      - wrap MYSQLparse with a function that would do a clean up.
      Rejected as ideally we should fix the problem when it happens, not
      adjust for it outside of the problematic code.
      - make sure MYSQLparse cleans up after itself by invoking the clean up
      functionality in the appropriate places before return. Implemented in 
      this patch.
      - use %destructor rule for sp_proc_stmt to restore THD - cleaner
      than the prevoius approach, but rejected
      because needs a careful analysis of the side effects, and this patch is 
      for 5.0, and long term we need to use the next alternative anyway
      - make sure that sp_proc_stmt doesn't juggle with THD - this is a 
      large work that will affect many modules.
      
      Cleanup: move main_lex and main_mem_root from Statement to its
      only two descendants Prepared_statement and THD. This ensures that
      when a Statement instance was created for purposes of statement backup,
      we do not involve LEX constructor/destructor, which is fairly expensive.
      In order to track that the transformation produces equivalent 
      functionality please check the respective constructors and destructors
      of Statement, Prepared_statement and THD - these members were
      used only there.
      This cleanup is unrelated to the patch.
      
      
      sql/log_event.cc:
        THD::main_lex is private and should not be used.
      sql/mysqld.cc:
        Move MYSQLerror to sql_yacc.yy as it depends on LEX headers now.
      sql/sql_class.cc:
        Cleanup: move main_lex and main_mem_root to THD and Prepared_statement
      sql/sql_class.h:
        Cleanup: move main_lex and main_mem_root to THD and Prepared_statement
      sql/sql_lex.cc:
        Implement st_lex::restore_lex()
      sql/sql_lex.h:
        Declare st_lex::restore_lex().
      sql/sql_parse.cc:
        Consolidate the calls to unit.cleanup() and deletion of lex->sphead
        in mysql_parse (COM_QUERY handler)
      sql/sql_prepare.cc:
        No need to delete lex->sphead to restore memory roots now in case of a 
        parse error - this is done automatically inside MYSQLparse
      sql/sql_trigger.cc:
        This code could lead to double deletion apparently, as in case
        of an error lex.sphead was never reset.
      sql/sql_yacc.yy:
        Trap all returns from the parser to ensure that MySQL-specific cleanup
        is invoked: we need to restore the global state of THD and LEX in 
        case of a parsing error. In case of a parsing success this happens as 
        part of normal grammar reduction process.
      053c6c01
    • unknown's avatar
      Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41 · c4390d05
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      c4390d05
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1-runtime · cd5140d3
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      
      cd5140d3
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · a966b0b7
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
      
      
      mysql-test/mysql-test-run.pl:
        Auto merged
      mysql-test/r/sp.result:
        Auto merged
      mysql-test/t/sp.test:
        Auto merged
      sql/item_cmpfunc.cc:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      sql/mysqld.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      a966b0b7
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-4.1 · b68519f7
      unknown authored
      into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/41
      
      
      b68519f7
  2. 06 Mar, 2007 8 commits
    • unknown's avatar
      Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0-maint · 31fc397c
      unknown authored
      into  siva.hindu.god:/home/tsmith/m/bk/maint/50
      
      
      31fc397c
    • unknown's avatar
      Merge siva.hindu.god:/home/tsmith/m/bk/maint/mar05/50 · 60997075
      unknown authored
      into  siva.hindu.god:/home/tsmith/m/bk/maint/50
      
      
      libmysql/libmysql.c:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      60997075
    • unknown's avatar
      Bug #25075: sql_class.cc doesn't compile with --without-query-cache · 5fdfea00
      unknown authored
      Wrap query_cache_init_query() call with #ifdef HAVE_QUERY_CACHE in THD::THD()
      
      
      5fdfea00
    • unknown's avatar
      Fix for bug #25595 "missing DBUG_RETURN in function "mysql_stat"" · 9a1ec4d3
      unknown authored
      
      libmysql/libmysql.c:
        Fix for bug #25595 "missing DBUG_RETURN in function "mysql_stat""
        
        Use DBUG_RETURN instead of return
      9a1ec4d3
    • unknown's avatar
      Manual merge · f7414b28
      unknown authored
      f7414b28
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 307c9f1e
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-8407_b
      
      
      mysql-test/r/view.result:
        Auto merged
      sql/mysqld.cc:
        Auto merged
      sql/sp_head.cc:
        Auto merged
      sql/sp_head.h:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_update.cc:
        Auto merged
      sql/table.cc:
        Auto merged
      sql/table.h:
        Auto merged
      sql/sql_base.cc:
        Manual merge
      307c9f1e
    • unknown's avatar
      Merge polly.local:/tmp/maint/bug20293/my50-bug20293 · 3e42ddda
      unknown authored
      into  polly.local:/home/kaa/src/maint/mysql-5.0-maint
      
      
      mysql-test/r/func_time.result:
        Manual merge.
      mysql-test/t/func_time.test:
        Manual merge.
      3e42ddda
    • unknown's avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · 266a7fff
      unknown 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.
      
      
      mysql-test/r/information_schema_db.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp-error.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/sp.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/trigger.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/r/view.result:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp-error.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/sp.test:
        Revised the pre-locking code implementation, aligned the tests.
      mysql-test/t/trigger.test:
        Revised the pre-locking code implementation, aligned the tests.
      sql/lock.cc:
        table->placeholder now checks for schema_table
      sql/mysqld.cc:
        my_message_sql(): invoke internal exception handlers
      sql/sp_head.cc:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sp_head.h:
        exec_open_and_lock_tables(): open and lock tables, or return the
        continuation destination of this instruction
      sql/sql_base.cc:
        Prelock_error_handler: delay open table errors until execution
      sql/sql_class.cc:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_class.h:
        THD: add internal error handler, as an exception mechanism.
      sql/sql_update.cc:
        table->placeholder now checks for schema_table
      sql/table.cc:
        st_table_list::hide_view_error(): masked more errors for view security
      sql/table.h:
        table->placeholder now checks for schema_table, and unopened tables
      266a7fff
  3. 05 Mar, 2007 7 commits
  4. 03 Mar, 2007 1 commit
  5. 02 Mar, 2007 7 commits
    • unknown's avatar
      Bug #21103: DATE column not compared as DATE · fed9bb98
      unknown authored
      If we compare two items A and B, with B being (a constant) of a
      larger type, then A gets promoted to B's type for comparison if
      it's a constant, function, or CAST() column, but B gets demoted
      to A's type if A is a (not explicitly CAST()) column. This is
      counter-intuitive and not mandated by the standard.
       
      Disabling optimisation where it would be lossy so field value
      will properly get promoted and compared as binary string (rather
      than as integers).
      
      
      mysql-test/include/ps_conv.inc:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/func_time.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Show that everything works as expected.
      mysql-test/r/ps_2myisam.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_3innodb.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_4heap.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_5merge.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_7ndb.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/t/func_time.test:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Show that everything works as expected.
      sql/field.cc:
        Bug #21103: DATE column not compared as DATE
        
        #0 stores the date only as a 3-byte integer; save_in_field() in
        #1 saves 'this' in field's format (DATE), #2 "converts a constant
        item to an int and replaces the original item" -- consequently,
        this replaces the Item_string "2006-11-06 04:08:36.0" with the
        Item_int_with_ref 20061106.
        
        #0  Field_newdate::store (this=0x8d26880, from=0x8d5e658 "2006-11-06
        04:08:36.0", len=21, cs=0x88022c0) at field.cc:5344
        #1  0x0817e3b0 in Item_string::save_in_field (this=0x8d5e670, field=0x8d26880, no_conversions=true) at item.cc:4340
        #2  0x081b22ae in convert_constant_item (thd=0x8d25240, field=0x8d26880, item=0x8d5e74c) at item_cmpfunc.cc:245
        #3  0x081b8a36 in Item_bool_func2::fix_length_and_dec (this=0x8d5e6f8) at item_cmpfunc.cc:309
        #4  0x081a3427 in Item_func::fix_fields (this=0x8d5e6f8, thd=0x8d25240, ref=0x8d5f5fc) at item_func.cc:190
        #5  0x0825bc2d in setup_conds (thd=0x8d25240, tables=0x8d5e410, leaves=0x8d5e410, conds=0x8d5f5fc) at sql_base.cc:4941
        ...
        
        Disabling optimisation where it would be lossy so field value will
        properly get promoted and compared as binary string (rather than as
        integers).
      fed9bb98
    • unknown's avatar
      Freeze the number of conflicts. We should not introduce any more · f7f5f006
      unknown authored
      conflicts without proper analysis and documentation of the nature of
      the conflict.
      
      
      f7f5f006
    • unknown's avatar
      Rename a macro to better reflect the action taken. · b0e07932
      unknown authored
      
      sql/sql_yacc.yy:
        Rename: YYERROR_UNLESS -> YYABORT_UNLESS
        yyerror doesn't have to abort of the parser, whereas this macro
        does explicitly call YYABORT.
      b0e07932
    • unknown's avatar
      after merge fix (bug #26038) · d4272a16
      unknown authored
      Item_func_geometry_from_text::val_str() should set null_value
      in case of wrong data.
      
      
      mysql-test/include/gis_generic.inc:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      mysql-test/r/archive_gis.result:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      mysql-test/r/gis.result:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      mysql-test/r/innodb_gis.result:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      mysql-test/r/ndb_gis.result:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      mysql-test/t/gis.test:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      sql/item_geofunc.cc:
        after merge fix
        
        Item_func_geometry_from_text::val_str() should set null_value
        in case of wrong data.
      d4272a16
    • unknown's avatar
      Merge mysql.com:/home/ram/work/b23616/b23616.4.1 · 7fc2a2a7
      unknown authored
      into  mysql.com:/home/ram/work/b23616/b23616.5.0
      
      
      mysql-test/r/func_sapdb.result:
        Auto merged
      mysql-test/r/func_time.result:
        Auto merged
      mysql-test/t/func_time.test:
        Auto merged
      sql-common/my_time.c:
        Auto merged
      7fc2a2a7
    • unknown's avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 133e08af
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-26093
      
      
      sql/item_func.cc:
        Auto merged
      133e08af
    • unknown's avatar
      Bug#26093 (SELECT BENCHMARK() for SELECT statements does not produce valid · 0a93be28
      unknown authored
        results)
      
      Before this fix, the function BENCHMARK() would fail to evaluate expressions
      like "(select avg(a) from t1)" in debug builds (with an assert),
      or would report a time of zero in non debug builds.
      
      The root cause is that evaluation of DECIMAL_RESULT expressions was not
      supported in Item_func_benchmark::val_int().
      
      This has been fixed by this change.
      
      
      mysql-test/r/func_misc.result:
        Added support for DECIMAL_RESULT in Item_func_benchmark::val_int()
      mysql-test/t/func_misc.test:
        Added support for DECIMAL_RESULT in Item_func_benchmark::val_int()
      sql/item_func.cc:
        Added support for DECIMAL_RESULT in Item_func_benchmark::val_int()
      0a93be28
  6. 01 Mar, 2007 8 commits
    • unknown's avatar
      Manual merge of 5.0 into 5.0-runtime · 09d82a1a
      unknown authored
      
      mysql-test/r/subselect.result:
        Manual merge
      mysql-test/t/subselect.test:
        Manual merge
      09d82a1a
    • unknown's avatar
      Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base · 57b6c864
      unknown authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
      
      
      mysql-test/mysql-test-run.pl:
        Auto merged
      mysql-test/t/disabled.def:
        Auto merged
      server-tools/instance-manager/instance_options.cc:
        Auto merged
      server-tools/instance-manager/mysqlmanager.cc:
        Auto merged
      sql/item_cmpfunc.cc:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      sql/item_subselect.cc:
        Auto merged
      sql/item_subselect.h:
        Auto merged
      sql/sp_head.cc:
        Auto merged
      sql/sql_base.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_lex.cc:
        Auto merged
      sql/sql_lex.h:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_yacc.yy:
        Auto merged
      57b6c864
    • unknown's avatar
      After merge fixes · 6e6fa326
      unknown authored
      6e6fa326
    • unknown's avatar
      Merge pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint · 0e6a060c
      unknown authored
      into  pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
      
      
      client/mysqltest.c:
        Auto merged
      mysql-test/mysql-test-run.pl:
        Auto merged
      mysql-test/lib/mtr_misc.pl:
        Auto merged
      sql/mysqld.cc:
        Auto merged
      0e6a060c
    • unknown's avatar
      Add two more USE_CYGWIN ifdefs to mysqltest · 115a299f
      unknown authored
      115a299f
    • unknown's avatar
    • unknown's avatar
      Don't set the "is_windows" flag if using cygwin · a01e8043
      unknown authored
      a01e8043
    • unknown's avatar
      Merge pilot.blaudden:/home/msvensson/mysql/mysql-5.0 · 4a9edcc3
      unknown authored
      into  pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
      
      
      BitKeeper/etc/ignore:
        auto-union
      client/mysqltest.c:
        Auto merged
      extra/comp_err.c:
        Auto merged
      include/my_time.h:
        Auto merged
      mysql-test/r/innodb.result:
        Auto merged
      mysql-test/r/mysqltest.result:
        Auto merged
      mysql-test/r/type_blob.result:
        Auto merged
      mysql-test/t/mysqltest.test:
        Auto merged
      sql/item.cc:
        Auto merged
      sql/item_cmpfunc.cc:
        Auto merged
      sql/item_cmpfunc.h:
        Auto merged
      sql/item_strfunc.cc:
        Auto merged
      sql/log.cc:
        Auto merged
      sql/mysql_priv.h:
        Auto merged
      sql/mysqld.cc:
        Auto merged
      sql/set_var.cc:
        Auto merged
      sql/sql_class.cc:
        Auto merged
      sql/sql_class.h:
        Auto merged
      sql/sql_load.cc:
        Auto merged
      sql/sql_parse.cc:
        Auto merged
      sql/sql_select.cc:
        Auto merged
      sql/tztime.cc:
        Auto merged
      client/mysql_upgrade.c:
        Manual merge
      mysql-test/mysql-test-run.pl:
        Manual merge
      mysql-test/r/ctype_cp932.result:
        Manual merge
      mysql-test/r/mysqlbinlog.result:
        Manual merge
      mysql-test/t/ctype_cp932.test:
        Manual merge
      mysql-test/t/mysql.test:
        Manual merge
      mysql-test/t/mysqlbinlog.test:
        Manual merge
      4a9edcc3