Skip to content
  • Tatjana Azundris Nuernberg's avatar
    0cf5f657
    WL#5928: Most statements should clear the diagnostic area · 0cf5f657
    Tatjana Azundris Nuernberg authored
    Previously, the errors/warnings list was only cleared when
    a statement accessed tables. This was non-standard. We now
    clear the DA for every procedure statement (mostly anything
    that is executed and is not a diagnostics statement like
    GET DIAGNOSTICS or SHOW WARNINGS).
    
    This changes both code and behaviour for
    - direct invocation
    - stored procedures/functions
    - prepared statements
    - query cache
    
    GET DIAGNOSTICS and the old SHOW WARNINGS, SHOW ERRORS,
    SHOW COUNT(*) WARNINGS, SHOW COUNT(*) ERRORS are diagnostics
    statements. They do not clear the diagnostics area even
    when issued repeatedly.
    
    @@error_count and @@warning_count are "diagnostics variables"
    and will appear in non-diagnostics statements like SELECT.
    For backward compatibility, they will contain the correct
    values describing the previous statement when queried
    immediately after execution of the previous statement:
    DROP TABLE does_not_exist;
    SELECT @@error_count;      # renders 1 (result of DROP)
    SELECT @@error_count;      # renders 0 (result of SELECT)
    This is discouraged; use GET DIAGNOSTICS instead.
    
    Likewise, SHOW WARNINGS could be used as the first
    statement of a HANDLER (or preceeded only by other
    diagnostics statements), but this is discouraged --
    use GET [STACKED] DIAGNOSTICS instead.
    
    Errors during parsing correctly set the DA; any
    errors thrown there replace the previous command's
    diagnostics, even if it was a diagnostics statement
    the user failed at issuing.
    
    The SQL standard requires the diagnostics statement
    (GET DIAGNOSTICS) not to be preparable; likewise,
    SHOW WARNINGS, SHOW ERRORS, and statements containing
    @@error_count or @@warning_count must not be used in
    prepared statements.
    
    Code:
    DA resetting was sprinkled all over the code, sometimes
    in the form of a "maybe" (opt_reset_condition_info()).
    All occurences of the latter were removed.
    Care was taken to reduce the number of occurences of the
    former, usually to one central point for each subsystem
    (parsing, SP, PS, QC, signaling, logging).
    Self-printing of SP instructions was slightly extended
    and refactored.
    
    Tests:
    wl5928.test tests and documents the new expected behaviour.
    Various other tests were adapted to provided similarly
    expressive results as they used to under the previous
    circumstances.
    0cf5f657
    WL#5928: Most statements should clear the diagnostic area
    Tatjana Azundris Nuernberg authored
    Previously, the errors/warnings list was only cleared when
    a statement accessed tables. This was non-standard. We now
    clear the DA for every procedure statement (mostly anything
    that is executed and is not a diagnostics statement like
    GET DIAGNOSTICS or SHOW WARNINGS).
    
    This changes both code and behaviour for
    - direct invocation
    - stored procedures/functions
    - prepared statements
    - query cache
    
    GET DIAGNOSTICS and the old SHOW WARNINGS, SHOW ERRORS,
    SHOW COUNT(*) WARNINGS, SHOW COUNT(*) ERRORS are diagnostics
    statements. They do not clear the diagnostics area even
    when issued repeatedly.
    
    @@error_count and @@warning_count are "diagnostics variables"
    and will appear in non-diagnostics statements like SELECT.
    For backward compatibility, they will contain the correct
    values describing the previous statement when queried
    immediately after execution of the previous statement:
    DROP TABLE does_not_exist;
    SELECT @@error_count;      # renders 1 (result of DROP)
    SELECT @@error_count;      # renders 0 (result of SELECT)
    This is discouraged; use GET DIAGNOSTICS instead.
    
    Likewise, SHOW WARNINGS could be used as the first
    statement of a HANDLER (or preceeded only by other
    diagnostics statements), but this is discouraged --
    use GET [STACKED] DIAGNOSTICS instead.
    
    Errors during parsing correctly set the DA; any
    errors thrown there replace the previous command's
    diagnostics, even if it was a diagnostics statement
    the user failed at issuing.
    
    The SQL standard requires the diagnostics statement
    (GET DIAGNOSTICS) not to be preparable; likewise,
    SHOW WARNINGS, SHOW ERRORS, and statements containing
    @@error_count or @@warning_count must not be used in
    prepared statements.
    
    Code:
    DA resetting was sprinkled all over the code, sometimes
    in the form of a "maybe" (opt_reset_condition_info()).
    All occurences of the latter were removed.
    Care was taken to reduce the number of occurences of the
    former, usually to one central point for each subsystem
    (parsing, SP, PS, QC, signaling, logging).
    Self-printing of SP instructions was slightly extended
    and refactored.
    
    Tests:
    wl5928.test tests and documents the new expected behaviour.
    Various other tests were adapted to provided similarly
    expressive results as they used to under the previous
    circumstances.
Loading