Bug#35981: ALTER EVENT causes the server to change the PRESERVE option.

If [NOT] PRESERVE was not given, parser always defaulted to NOT
PRESERVE, making it impossible for the "not given = no change"
rule to work in ALTER EVENT. Leaving out the PRESERVE-clause
defaults to NOT PRESERVE on CREATE now, and to "no change" in
ALTER.

mysql-test/r/events_2.result:
  show that giving no PRESERVE-clause to ALTER EVENT
  results in no change. show that giving no PRESERVE-clause
  to CREATE EVENT defaults to NOT PRESERVE as per the docs.
  Show specifically that this is also handled correctly when
  trying to ALTER EVENTs into the past.
mysql-test/t/events_2.test:
  show that giving no PRESERVE-clause to ALTER EVENT
  results in no change. show that giving no PRESERVE-clause
  to CREATE EVENT defaults to NOT PRESERVE as per the docs.
  Show specifically that this is also handled correctly when
  trying to ALTER EVENTs into the past.
sql/event_db_repository.cc:
  If ALTER EVENT was given no PRESERVE-clause (meaning "no change"),
  we don't know the previous PRESERVE-setting by the time we check
  the parse-data. If ALTER EVENT was given dates that are in the past,
  we don't know how to react, lacking the PRESERVE-setting. Heal this
  by running the check later when we have actually read the previous
  EVENT-data.
sql/event_parse_data.cc:
  Change default for ON COMPLETION to indicate, "not specified."
  Also defer throwing errors when ALTER EVENT is given dates in
  the past but not PRESERVE-clause until we know the previous
  PRESERVE-value.
sql/event_parse_data.h:
  Add third state for ON COMPLETION [NOT] PRESERVE (preserve,
  don't, not specified).
  
  Make check_dates() public so we can defer this check until
  deeper in the callstack where we have all the required data.
sql/sql_yacc.yy:
  If CREATE EVENT is not given ON COMPLETION [NOT] PRESERVE,
  we default to NOT, as per the docs.

1 files changed, 102 insertions, 0 deletions

diff --git a/mysql-test/t/events_2.test b/mysql-test/t/events_2.test
index 58a6fffe6f5..a50255e9f8b 100644
--- a/mysql-test/t/events_2.test
+++ b/mysql-test/t/events_2.test
@@ -411,6 +411,108 @@ create event
 очень_очень_очень_очень_очень_очень_очень_очень_длинная_строка_66
 on schedule every 2 year do select 1;
 
+#
+# Bug#35981: ALTER EVENT causes the server to change the PRESERVE option.
+#
+
+create event event_35981 on schedule every 6 month on completion preserve
+disable
+do
+  select 1;
+
+echo The following SELECTs should all give 1;
+
+# show current ON_COMPLETION
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'PRESERVE';
+
+# show ON_COMPLETION remains "PRESERVE" when not given in ALTER EVENT
+alter   event event_35981 enable;
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'PRESERVE';
+
+# show we can change ON_COMPLETION
+alter   event event_35981 on completion not preserve;
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'NOT PRESERVE';
+
+# show ON_COMPLETION remains "NOT PRESERVE" when not given in ALTER EVENT
+alter   event event_35981 disable;
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'NOT PRESERVE';
+
+# show we can change ON_COMPLETION
+alter   event event_35981 on completion preserve;
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'PRESERVE';
+
+
+drop event event_35981;
+
+create event event_35981 on schedule every 6 month disable
+do
+  select 1;
+
+# show that the defaults for CREATE EVENT are still correct (NOT PRESERVE)
+select  count(*) from information_schema.events
+where   event_schema = database() and event_name = 'event_35981' and
+        on_completion = 'NOT PRESERVE';
+
+drop event event_35981;
+
+
+# show that backdating doesn't break
+
+create event event_35981 on schedule every 1 hour starts current_timestamp
+  on completion not preserve
+do
+  select 1;
+
+# should fail thanks to above's NOT PRESERVE
+--error ER_EVENT_CANNOT_ALTER_IN_THE_PAST
+alter event event_35981 on schedule every 1 hour starts '1999-01-01 00:00:00'
+  ends '1999-01-02 00:00:00';
+
+drop event event_35981;
+
+create event event_35981 on schedule every 1 hour starts current_timestamp
+  on completion not preserve
+do
+  select 1;
+
+# succeed with warning
+alter event event_35981 on schedule every 1 hour starts '1999-01-01 00:00:00'
+  ends '1999-01-02 00:00:00' on completion preserve;
+
+drop event event_35981;
+
+
+
+create event event_35981 on schedule every 1 hour starts current_timestamp
+  on completion preserve
+do
+  select 1;
+
+# this should succeed thanks to above PRESERVE! give a warning though.
+alter event event_35981 on schedule every 1 hour starts '1999-01-01 00:00:00'
+  ends '1999-01-02 00:00:00';
+
+# this should fail, as the event would have passed already
+--error ER_EVENT_CANNOT_ALTER_IN_THE_PAST
+alter event event_35981 on schedule every 1 hour starts '1999-01-01 00:00:00'
+  ends '1999-01-02 00:00:00' on completion not preserve;
+
+# should succeed giving a warning
+alter event event_35981 on schedule every 1 hour starts '1999-01-01 00:00:00'
+  ends '1999-01-02 00:00:00' on completion preserve;
+
+drop event event_35981;
+
 # 
 # End of tests
 #