1. 20 May, 2014 1 commit
  2. 14 May, 2014 1 commit
  3. 06 May, 2014 1 commit
  4. 05 Apr, 2014 2 commits
  5. 01 Apr, 2014 2 commits
  6. 19 Mar, 2014 1 commit
  7. 16 Mar, 2014 1 commit
  8. 13 Mar, 2014 3 commits
  9. 12 Mar, 2014 3 commits
  10. 10 Mar, 2014 3 commits
  11. 06 Mar, 2014 2 commits
  12. 26 Feb, 2014 1 commit
  13. 24 Feb, 2014 1 commit
  14. 19 Feb, 2014 1 commit
  15. 12 Feb, 2014 1 commit
    • Add support for string values · 811aa261
      The SET GLOBAL statement requires properly quoting of values. For example, the
      following correct queries will fail if quotes are toggled:
      
      mysql> SET GLOBAL innodb_lru_scan_depth = 2000;
      mysql> SET GLOBAL master_info_repository = "TABLE";
      
      `mysql_variable` module doesn't quote the value argument, therefore
      string values will fail.
      
        # this task will pass, 2000 is passed without quotes
        - name: set a numeric value
          mysql_variable: variable=innodb_lru_scan_depth value=2000
      
        # this task will fail, TABLE is passed without quotes
        - name: set a string value
          mysql_variable: variable=master_info_repository value=TABLE
      
      With this patch prepared statements are used. Proper quoting will be
      done automatically based on the type of the variables thus an attempt
      to convert to int, then to float is done in first place.
      
      Booleans values, ie: ON, OFF, are not specially handled because they
      can be quoted. For example, the following queries are correct and
      equivalent, they all set _innodb_file_per_table_ to logical _True_:
      
      mysql> SET GLOBAL innodb_file_per_table = "ON";
      mysql> SET GLOBAL innodb_file_per_table = ON;
      mysql> SET GLOBAL innodb_file_per_table = 1;
      
      Tested in mysql 5.5 and 5.6.
      Maykel Moya committed
  16. 07 Feb, 2014 1 commit
  17. 04 Feb, 2014 1 commit
  18. 03 Feb, 2014 2 commits
  19. 26 Jan, 2014 1 commit
  20. 14 Jan, 2014 1 commit
  21. 04 Jan, 2014 1 commit
    • Fix postgresql_user to understand PG namespaces · 7a860838
      Previously postgresql_user quoted user supplied identifers to create
      grant statements that look like this:
      
          GRANT SELECT on "tablename" to "user";
      
      Which only works if the tablename is not in a namespace.  If you supply
      a namespaced tabelname like "report.revenue" then it creates this
      incorrect statement:
      
          GRANT SELECT on "report.revenue" to "user";
      
      Which will not find the "revenue" table in the "report" namespace, but
      will rather look for a table named "report.revenue" in the current
      (default public) namespace.  The correct form is:
      
          GRANT SELECT on "report"."revenue" to "user";
      
      This approach could have the unfortunate effect that code that
      previously relied on the other behavior to grant privileges on tables
      with periods in their names may now break.  PostgreSQL users
      typically shouldn't name tables as such, and users can still access the
      old behavior and use tablenames with periods in the if they must by
      supplying their own quoting.
      Alan Fairless committed
  22. 02 Jan, 2014 1 commit
  23. 31 Dec, 2013 1 commit
  24. 27 Dec, 2013 1 commit
  25. 05 Dec, 2013 2 commits
  26. 02 Dec, 2013 2 commits
  27. 29 Nov, 2013 1 commit
  28. 28 Nov, 2013 1 commit