1. 28 Apr, 2011 2 commits
    • Rafal Somla's avatar
      BUG#11879051: FIRST REPLY LENGTH LIMIT (255) CAN BE VIOLATED · 32cc7d19
      Rafal Somla authored
      BEFORE: First packet sent by client-side plugin (generated by Windows
      function InitializeSecurityContext()) could be longer than 255 bytes 
      violating the limitation imposed by authentication protocol.
      
      AFTER: Handshake protocol is  changed so that if first client's reply is 
      longer than 254 bytes then  it is be sent in 2 parts. However, for replies
      shorter than 255 bytes nothing changes.
      
      ADDITIONAL CHANGES: 
      - The generic packet processing loop  (Handshake::packet_processing_loop) 
      has been refactored. Communication with the peer has been abstracted
      into virtual methods read/write_packet() which are implemented in client 
      and server and transparently do the required splitting and gluing of packets.
      - Make it possible to optionally use dbug library in the plugin.
      - Add code for testing splitting of long first client reply.
      32cc7d19
    • Rafal Somla's avatar
      Bug#11766631 (59780) - Move the client authentication_windows plugin · c50c571f
      Rafal Somla authored
      into the server repository
      
      This patch adds client windows authentication plugin code to the client 
      library libmysql (only on Windows platform). The plugin is compiled into 
      the library and added to the list of built-in plugins. This way clients 
      should be able to connect to a server which uses windows authentication 
      plugin even as an SQL user which uses such authentication.
      
      Note: this makes the client library to depend on Secur32 Windows system
      library. When building clients, they must be linked against Secur32. 
      Command mysql_config --libs correctly lists Secur32 as a required 
      dependency.
      c50c571f
  2. 29 Apr, 2011 11 commits
  3. 28 Apr, 2011 2 commits
  4. 27 Apr, 2011 9 commits
  5. 26 Apr, 2011 9 commits
  6. 25 Apr, 2011 2 commits
  7. 23 Apr, 2011 3 commits
  8. 22 Apr, 2011 2 commits
    • Sergey Glukhov's avatar
      5.1 -> 5.5 merge · ec9bd00e
      Sergey Glukhov authored
      ec9bd00e
    • Sergey Glukhov's avatar
      Bug#11756928 48916: SERVER INCORRECTLY PROCESSING HAVING CLAUSES WITH AN ORDER BY CLAUSE · 801b0ca2
      Sergey Glukhov authored
      Before sorting HAVING condition is split into two parts,
      first part is a table related condition and the rest of is
      HAVING part. Extraction of HAVING part does not take into account
      the fact that some of conditions might be non-const but
      have 'used_tables' == 0 (independent subqueries)
      and because of that these conditions are cut off by
      make_cond_for_table() function.
      The fix is to use (table_map) 0 instead of used_tables in
      third argument for make_cond_for_table() function.
      It allows to extract elements which belong to sorted
      table and in addition elements which are independend
      subqueries.
      
      
      mysql-test/r/having.result:
        test case
      mysql-test/t/having.test:
        test case
      sql/sql_select.cc:
        The fix is to use (table_map) 0 instead of used_tables in
        third argument for make_cond_for_table() function.
        It allows to extract elements which belong to sorted
        table and in addition elements which are independend
        subqueries.
      801b0ca2