2009-09-23 23:32:31 +02:00
|
|
|
#ifndef SQL_TRIGGER_INCLUDED
|
|
|
|
#define SQL_TRIGGER_INCLUDED
|
|
|
|
|
2011-07-04 01:25:49 +02:00
|
|
|
/*
|
2011-11-21 19:13:14 +02:00
|
|
|
Copyright (c) 2004, 2011, Oracle and/or its affiliates.
|
2022-10-27 22:18:51 +02:00
|
|
|
Copyright (c) 2017, MariaDB Corporation.
|
2005-07-09 21:51:59 +04:00
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2006-12-23 20:17:15 +01:00
|
|
|
the Free Software Foundation; version 2 of the License.
|
2005-07-09 21:51:59 +04:00
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
2019-05-11 21:29:06 +03:00
|
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1335 USA */
|
2005-07-09 21:51:59 +04:00
|
|
|
|
2015-10-23 11:31:18 +02:00
|
|
|
#include <mysqld_error.h>
|
|
|
|
|
2010-03-31 16:05:33 +02:00
|
|
|
/* Forward declarations */
|
|
|
|
|
|
|
|
class Item_trigger_field;
|
|
|
|
class sp_head;
|
|
|
|
class sp_name;
|
|
|
|
class Query_tables_list;
|
|
|
|
struct TABLE_LIST;
|
|
|
|
class Query_tables_list;
|
2020-12-14 15:57:04 +02:00
|
|
|
typedef struct st_ddl_log_state DDL_LOG_STATE;
|
2010-03-31 16:05:33 +02:00
|
|
|
|
2025-01-24 19:22:02 +07:00
|
|
|
#include <sql_list.h>
|
|
|
|
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
static const uint8 TRG_EVENT_UNKNOWN= 0;
|
2010-03-31 16:05:33 +02:00
|
|
|
/** Event on which trigger is invoked. */
|
|
|
|
enum trg_event_type
|
|
|
|
{
|
|
|
|
TRG_EVENT_INSERT= 0,
|
|
|
|
TRG_EVENT_UPDATE= 1,
|
|
|
|
TRG_EVENT_DELETE= 2,
|
|
|
|
TRG_EVENT_MAX
|
|
|
|
};
|
|
|
|
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
typedef uint8 trg_event_set;
|
|
|
|
|
2019-01-05 11:49:35 +01:00
|
|
|
static inline uint8 trg2bit(enum trg_event_type trg)
|
|
|
|
{ return static_cast<uint8>(1 << static_cast<int>(trg)); }
|
|
|
|
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
/**
|
|
|
|
Check whether the specified trigger event type is set in
|
|
|
|
the trigger's event mask
|
|
|
|
*/
|
|
|
|
static inline bool is_trg_event_on(uint8 trg_event_mask,
|
|
|
|
enum trg_event_type event_type)
|
|
|
|
{
|
|
|
|
return (trg_event_mask & trg2bit(event_type)) != 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Check whether the specified trigger event type is the right most event bit
|
|
|
|
that is set in the trigger's event mask
|
|
|
|
*/
|
|
|
|
static inline bool is_the_right_most_event_bit(trg_event_set events,
|
|
|
|
trg_event_type event_type)
|
|
|
|
{
|
|
|
|
return (1 << event_type) == (events & ~((events - 1) & events));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
Check whether trg_events_mask includes all bits of trg_events
|
|
|
|
*/
|
|
|
|
static inline bool is_subset_of_trg_events(trg_event_set trg_events_mask,
|
|
|
|
trg_event_set trg_events)
|
|
|
|
{
|
|
|
|
return (trg_events_mask & trg_events) == trg_events;
|
|
|
|
}
|
|
|
|
|
2010-03-31 16:05:33 +02:00
|
|
|
#include "table.h" /* GRANT_INFO */
|
|
|
|
|
|
|
|
/*
|
|
|
|
We need this two enums here instead of sql_lex.h because
|
|
|
|
at least one of them is used by Item_trigger_field interface.
|
|
|
|
|
|
|
|
Time when trigger is invoked (i.e. before or after row actually
|
|
|
|
inserted/updated/deleted).
|
|
|
|
*/
|
|
|
|
enum trg_action_time_type
|
|
|
|
{
|
|
|
|
TRG_ACTION_BEFORE= 0, TRG_ACTION_AFTER= 1, TRG_ACTION_MAX
|
|
|
|
};
|
|
|
|
|
2016-10-02 15:35:08 +03:00
|
|
|
enum trigger_order_type
|
|
|
|
{
|
|
|
|
TRG_ORDER_NONE= 0,
|
|
|
|
TRG_ORDER_FOLLOWS= 1,
|
|
|
|
TRG_ORDER_PRECEDES= 2
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
struct st_trg_execution_order
|
|
|
|
{
|
|
|
|
/**
|
|
|
|
FOLLOWS or PRECEDES as specified in the CREATE TRIGGER statement.
|
|
|
|
*/
|
|
|
|
enum trigger_order_type ordering_clause;
|
|
|
|
|
|
|
|
/**
|
|
|
|
Trigger name referenced in the FOLLOWS/PRECEDES clause of the
|
|
|
|
CREATE TRIGGER statement.
|
2023-04-26 15:27:01 +04:00
|
|
|
Cannot be Lex_ident_trigger,
|
|
|
|
as this structure is used in %union in sql_yacc.yy
|
2016-10-02 15:35:08 +03:00
|
|
|
*/
|
2023-04-26 15:27:01 +04:00
|
|
|
LEX_CSTRING anchor_trigger_name; // Used in sql_yacc %union
|
2016-10-02 15:35:08 +03:00
|
|
|
};
|
2005-07-09 21:51:59 +04:00
|
|
|
|
2004-09-07 16:29:46 +04:00
|
|
|
|
2021-03-22 16:05:08 +02:00
|
|
|
/*
|
|
|
|
Parameter to change_table_name_in_triggers()
|
|
|
|
*/
|
|
|
|
|
|
|
|
class TRIGGER_RENAME_PARAM
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
TABLE table;
|
|
|
|
bool upgrading50to51;
|
|
|
|
bool got_error;
|
|
|
|
|
|
|
|
TRIGGER_RENAME_PARAM()
|
|
|
|
{
|
|
|
|
upgrading50to51= got_error= 0;
|
|
|
|
table.reset();
|
|
|
|
}
|
|
|
|
~TRIGGER_RENAME_PARAM()
|
|
|
|
{
|
|
|
|
reset();
|
|
|
|
}
|
|
|
|
void reset();
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2016-10-02 15:35:08 +03:00
|
|
|
class Table_triggers_list;
|
|
|
|
|
|
|
|
/**
|
|
|
|
The trigger object
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
One instance of the Trigger class can handle several trigger events.
|
|
|
|
E.g., one object of the Trigger class can be instantiated to handle
|
|
|
|
every of events INSERT, UPDATE, DELETE.
|
|
|
|
Since one instance of the Trigger class can be associated with several
|
|
|
|
trigger events, the data member `action_order` and `next` are represented
|
|
|
|
as an array of TRG_EVENT_MAX elements.
|
2004-09-07 16:29:46 +04:00
|
|
|
*/
|
2005-08-15 18:15:12 +03:00
|
|
|
|
2016-10-02 15:35:08 +03:00
|
|
|
class Trigger :public Sql_alloc
|
2004-09-07 16:29:46 +04:00
|
|
|
{
|
2016-10-02 15:35:08 +03:00
|
|
|
public:
|
|
|
|
Trigger(Table_triggers_list *base_arg, sp_head *code):
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
base(base_arg), body(code),
|
2025-01-24 19:22:02 +07:00
|
|
|
sql_mode{0},
|
|
|
|
hr_create_time{(unsigned long long)-1},
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
events{0},
|
2025-01-24 19:22:02 +07:00
|
|
|
action_time{TRG_ACTION_MAX},
|
|
|
|
updatable_columns{nullptr}
|
2016-10-02 15:35:08 +03:00
|
|
|
{
|
|
|
|
bzero((char *)&subject_table_grants, sizeof(subject_table_grants));
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
bzero(next, sizeof(next));
|
|
|
|
bzero(action_order, sizeof(action_order));
|
2016-10-02 15:35:08 +03:00
|
|
|
}
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
|
2016-10-02 15:35:08 +03:00
|
|
|
~Trigger();
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
|
2016-10-02 15:35:08 +03:00
|
|
|
Table_triggers_list *base;
|
|
|
|
sp_head *body;
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
/**
|
|
|
|
Next trigger of the same type in every of the event groups
|
|
|
|
*/
|
|
|
|
Trigger *next[TRG_EVENT_MAX];
|
2016-10-02 15:35:08 +03:00
|
|
|
|
2023-04-26 15:27:01 +04:00
|
|
|
Lex_ident_trigger name;
|
2017-04-23 19:39:57 +03:00
|
|
|
LEX_CSTRING on_table_name; /* Raw table name */
|
|
|
|
LEX_CSTRING definition;
|
|
|
|
LEX_CSTRING definer;
|
2016-10-02 15:35:08 +03:00
|
|
|
|
|
|
|
/* Character sets used */
|
2017-04-23 19:39:57 +03:00
|
|
|
LEX_CSTRING client_cs_name;
|
|
|
|
LEX_CSTRING connection_cl_name;
|
|
|
|
LEX_CSTRING db_cl_name;
|
2016-10-02 15:35:08 +03:00
|
|
|
|
|
|
|
GRANT_INFO subject_table_grants;
|
2016-10-02 16:39:40 +03:00
|
|
|
sql_mode_t sql_mode;
|
2016-10-02 15:35:08 +03:00
|
|
|
/* Store create time. Can't be mysql_time_t as this holds also sub seconds */
|
2019-04-17 15:50:59 +02:00
|
|
|
my_hrtime_t hr_create_time; // Create time timestamp in microseconds
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
/* Set of events this trigger object assigned to */
|
|
|
|
trg_event_set events;
|
2016-10-02 15:35:08 +03:00
|
|
|
trg_action_time_type action_time;
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
action order of the trigger for every of supplied event type
|
|
|
|
*/
|
|
|
|
uint action_order[TRG_EVENT_MAX];
|
2025-01-24 19:22:02 +07:00
|
|
|
List<LEX_CSTRING> *updatable_columns;
|
2016-10-02 15:35:08 +03:00
|
|
|
|
2017-04-23 19:39:57 +03:00
|
|
|
void get_trigger_info(LEX_CSTRING *stmt, LEX_CSTRING *body,
|
2016-10-02 15:35:08 +03:00
|
|
|
LEX_STRING *definer);
|
|
|
|
/* Functions executed over each active trigger */
|
|
|
|
bool change_on_table_name(void* param_arg);
|
|
|
|
bool change_table_name(void* param_arg);
|
|
|
|
bool add_to_file_list(void* param_arg);
|
2025-01-24 19:22:02 +07:00
|
|
|
|
|
|
|
bool match_updatable_columns(List<Item> &fields);
|
2016-10-02 15:35:08 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
typedef bool (Trigger::*Triggers_processor)(void *arg);
|
|
|
|
|
|
|
|
/**
|
|
|
|
This class holds all information about triggers of table.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class Table_triggers_list: public Sql_alloc
|
|
|
|
{
|
|
|
|
friend class Trigger;
|
|
|
|
|
|
|
|
/* Points to first trigger for a certain type */
|
|
|
|
Trigger *triggers[TRG_EVENT_MAX][TRG_ACTION_MAX];
|
2015-11-14 22:51:54 +01:00
|
|
|
/**
|
|
|
|
Copy of TABLE::Field array which all fields made nullable
|
|
|
|
(using extra_null_bitmap, if needed). Used for NEW values in
|
|
|
|
BEFORE INSERT/UPDATE triggers.
|
|
|
|
*/
|
|
|
|
Field **record0_field;
|
2024-12-23 21:27:00 +01:00
|
|
|
uchar *extra_null_bitmap, *extra_null_bitmap_init;
|
2007-10-16 16:11:50 -04:00
|
|
|
/**
|
2005-05-24 22:19:33 +04:00
|
|
|
Copy of TABLE::Field array with field pointers set to TABLE::record[1]
|
|
|
|
buffer instead of TABLE::record[0] (used for OLD values in on UPDATE
|
|
|
|
trigger and DELETE trigger when it is called for REPLACE).
|
2004-09-07 16:29:46 +04:00
|
|
|
*/
|
2005-05-24 22:19:33 +04:00
|
|
|
Field **record1_field;
|
2007-10-16 16:11:50 -04:00
|
|
|
/**
|
2005-05-24 22:19:33 +04:00
|
|
|
During execution of trigger new_field and old_field should point to the
|
|
|
|
array of fields representing new or old version of row correspondingly
|
|
|
|
(so it can point to TABLE::field or to Tale_triggers_list::record1_field)
|
|
|
|
*/
|
|
|
|
Field **new_field;
|
2004-09-07 16:29:46 +04:00
|
|
|
Field **old_field;
|
2006-12-15 00:51:37 +02:00
|
|
|
|
2005-05-24 22:19:33 +04:00
|
|
|
/* TABLE instance for which this triggers list object was created */
|
2006-12-15 00:51:37 +02:00
|
|
|
TABLE *trigger_table;
|
2005-11-10 22:25:03 +03:00
|
|
|
|
2011-06-10 10:52:39 +07:00
|
|
|
/**
|
|
|
|
This flag indicates that one of the triggers was not parsed successfully,
|
|
|
|
and as a precaution the object has entered a state where all trigger
|
|
|
|
access results in errors until all such triggers are dropped. It is not
|
|
|
|
safe to add triggers since we don't know if the broken trigger has the
|
|
|
|
same name or event type. Nor is it safe to invoke any trigger for the
|
|
|
|
aforementioned reasons. The only safe operations are drop_trigger and
|
|
|
|
drop_all_triggers.
|
|
|
|
|
|
|
|
@see Table_triggers_list::set_parse_error
|
|
|
|
*/
|
|
|
|
bool m_has_unparseable_trigger;
|
|
|
|
|
|
|
|
/**
|
|
|
|
This error will be displayed when the user tries to manipulate or invoke
|
|
|
|
triggers on a table that has broken triggers. It will get set only once
|
|
|
|
per statement and thus will contain the first parse error encountered in
|
|
|
|
the trigger file.
|
|
|
|
*/
|
|
|
|
char m_parse_error_message[MYSQL_ERRMSG_SIZE];
|
2016-10-02 15:35:08 +03:00
|
|
|
uint count; /* Number of triggers */
|
2011-06-10 10:52:39 +07:00
|
|
|
|
2004-09-07 16:29:46 +04:00
|
|
|
public:
|
2007-10-16 16:11:50 -04:00
|
|
|
/**
|
2004-09-07 16:29:46 +04:00
|
|
|
Field responsible for storing triggers definitions in file.
|
|
|
|
It have to be public because we are using it directly from parser.
|
|
|
|
*/
|
2017-04-23 19:39:57 +03:00
|
|
|
List<LEX_CSTRING> definitions_list;
|
2007-10-16 16:11:50 -04:00
|
|
|
/**
|
2005-07-28 22:39:11 +03:00
|
|
|
List of sql modes for triggers
|
|
|
|
*/
|
|
|
|
List<ulonglong> definition_modes_list;
|
2016-10-02 15:35:08 +03:00
|
|
|
/** Create times for triggers */
|
2019-04-17 15:50:59 +02:00
|
|
|
List<ulonglong> hr_create_times;
|
2004-09-07 16:29:46 +04:00
|
|
|
|
2017-04-23 19:39:57 +03:00
|
|
|
List<LEX_CSTRING> definers_list;
|
2005-11-10 22:25:03 +03:00
|
|
|
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
client/mysqldump.c:
Set original character set and collation before dumping definition query.
include/my_sys.h:
Move out-parameter to the end of list.
mysql-test/lib/mtr_report.pl:
Ignore server-warnings during the test case.
mysql-test/r/create.result:
Update result file.
mysql-test/r/ctype_cp932_binlog_stm.result:
Update result file.
mysql-test/r/events.result:
Update result file.
mysql-test/r/events_bugs.result:
Update result file.
mysql-test/r/events_grant.result:
Update result file.
mysql-test/r/func_in.result:
Update result file.
mysql-test/r/gis.result:
Update result file.
mysql-test/r/grant.result:
Update result file.
mysql-test/r/information_schema.result:
Update result file.
mysql-test/r/information_schema_db.result:
Update result file.
mysql-test/r/lowercase_view.result:
Update result file.
mysql-test/r/mysqldump.result:
Update result file.
mysql-test/r/ndb_sp.result:
Update result file.
mysql-test/r/ps.result:
Update result file.
mysql-test/r/rpl_replicate_do.result:
Update result file.
mysql-test/r/rpl_sp.result:
Update result file.
mysql-test/r/rpl_trigger.result:
Update result file.
mysql-test/r/rpl_view.result:
Update result file.
mysql-test/r/show_check.result:
Update result file.
mysql-test/r/skip_grants.result:
Update result file.
mysql-test/r/sp-destruct.result:
Update result file.
mysql-test/r/sp-error.result:
Update result file.
mysql-test/r/sp-security.result:
Update result file.
mysql-test/r/sp.result:
Update result file.
mysql-test/r/sql_mode.result:
Update result file.
mysql-test/r/system_mysql_db.result:
Update result file.
mysql-test/r/temp_table.result:
Update result file.
mysql-test/r/trigger-compat.result:
Update result file.
mysql-test/r/trigger-grant.result:
Update result file.
mysql-test/r/trigger.result:
Update result file.
mysql-test/r/view.result:
Update result file.
mysql-test/r/view_grant.result:
Update result file.
mysql-test/t/events.test:
Update test case (new columns added).
mysql-test/t/information_schema.test:
Update test case (new columns added).
mysql-test/t/show_check.test:
Test case for SHOW CREATE TRIGGER in prepared statements and
stored routines.
mysql-test/t/sp-destruct.test:
Update test case (new columns added).
mysql-test/t/sp.test:
Update test case (new columns added).
mysql-test/t/view.test:
Update test.
mysys/charset.c:
Move out-parameter to the end of list.
scripts/mysql_system_tables.sql:
Add new columns to mysql.proc and mysql.event.
scripts/mysql_system_tables_fix.sql:
Add new columns to mysql.proc and mysql.event.
sql/event_data_objects.cc:
Support new attributes for events.
sql/event_data_objects.h:
Support new attributes for events.
sql/event_db_repository.cc:
Support new attributes for events.
sql/event_db_repository.h:
Support new attributes for events.
sql/events.cc:
Add new columns to SHOW CREATE event resultset.
sql/mysql_priv.h:
1. Introduce Object_creation_ctx;
2. Introduce SHOW CREATE TRIGGER;
3. Introduce auxilary functions.
sql/sp.cc:
Add support for new store routines attributes.
sql/sp_head.cc:
Add support for new store routines attributes.
sql/sp_head.h:
Add support for new store routines attributes.
sql/sql_lex.cc:
Generate UTF8-body on parsing/lexing.
sql/sql_lex.h:
1. Generate UTF8-body on parsing/lexing.
2. Introduce SHOW CREATE TRIGGER.
sql/sql_parse.cc:
Introduce SHOW CREATE TRIGGER.
sql/sql_partition.cc:
Update parse_sql().
sql/sql_prepare.cc:
Update parse_sql().
sql/sql_show.cc:
Support new attributes for views
sql/sql_trigger.cc:
Support new attributes for views
sql/sql_trigger.h:
Support new attributes for views
sql/sql_view.cc:
Support new attributes for views
sql/sql_yacc.yy:
1. Add SHOW CREATE TRIGGER statement.
2. Generate UTF8-body for views, stored routines, triggers and events.
sql/table.cc:
Introduce Object_creation_ctx.
sql/table.h:
Introduce Object_creation_ctx.
sql/share/errmsg.txt:
Add new errors.
mysql-test/include/ddl_i18n.check_events.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_sp.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_triggers.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_views.inc:
Aux file for test suite.
mysql-test/include/have_cp1251.inc:
Aux file for test suite.
mysql-test/include/have_cp866.inc:
Aux file for test suite.
mysql-test/include/have_koi8r.inc:
Aux file for test suite.
mysql-test/include/have_utf8.inc:
Aux file for test suite.
mysql-test/r/ddl_i18n_koi8r.result:
Result file.
mysql-test/r/ddl_i18n_utf8.result:
Result file.
mysql-test/r/have_cp1251.require:
Aux file for test suite.
mysql-test/r/have_cp866.require:
Aux file for test suite.
mysql-test/r/have_koi8r.require:
Aux file for test suite.
mysql-test/r/have_utf8.require:
Aux file for test suite.
mysql-test/t/ddl_i18n_koi8r.test:
Complete koi8r test case for the CS patch.
mysql-test/t/ddl_i18n_utf8.test:
Complete utf8 test case for the CS patch.
2007-06-28 21:34:54 +04:00
|
|
|
/* Character set context, used for parsing and executing triggers. */
|
|
|
|
|
2017-04-23 19:39:57 +03:00
|
|
|
List<LEX_CSTRING> client_cs_names;
|
|
|
|
List<LEX_CSTRING> connection_cl_names;
|
|
|
|
List<LEX_CSTRING> db_cl_names;
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
client/mysqldump.c:
Set original character set and collation before dumping definition query.
include/my_sys.h:
Move out-parameter to the end of list.
mysql-test/lib/mtr_report.pl:
Ignore server-warnings during the test case.
mysql-test/r/create.result:
Update result file.
mysql-test/r/ctype_cp932_binlog_stm.result:
Update result file.
mysql-test/r/events.result:
Update result file.
mysql-test/r/events_bugs.result:
Update result file.
mysql-test/r/events_grant.result:
Update result file.
mysql-test/r/func_in.result:
Update result file.
mysql-test/r/gis.result:
Update result file.
mysql-test/r/grant.result:
Update result file.
mysql-test/r/information_schema.result:
Update result file.
mysql-test/r/information_schema_db.result:
Update result file.
mysql-test/r/lowercase_view.result:
Update result file.
mysql-test/r/mysqldump.result:
Update result file.
mysql-test/r/ndb_sp.result:
Update result file.
mysql-test/r/ps.result:
Update result file.
mysql-test/r/rpl_replicate_do.result:
Update result file.
mysql-test/r/rpl_sp.result:
Update result file.
mysql-test/r/rpl_trigger.result:
Update result file.
mysql-test/r/rpl_view.result:
Update result file.
mysql-test/r/show_check.result:
Update result file.
mysql-test/r/skip_grants.result:
Update result file.
mysql-test/r/sp-destruct.result:
Update result file.
mysql-test/r/sp-error.result:
Update result file.
mysql-test/r/sp-security.result:
Update result file.
mysql-test/r/sp.result:
Update result file.
mysql-test/r/sql_mode.result:
Update result file.
mysql-test/r/system_mysql_db.result:
Update result file.
mysql-test/r/temp_table.result:
Update result file.
mysql-test/r/trigger-compat.result:
Update result file.
mysql-test/r/trigger-grant.result:
Update result file.
mysql-test/r/trigger.result:
Update result file.
mysql-test/r/view.result:
Update result file.
mysql-test/r/view_grant.result:
Update result file.
mysql-test/t/events.test:
Update test case (new columns added).
mysql-test/t/information_schema.test:
Update test case (new columns added).
mysql-test/t/show_check.test:
Test case for SHOW CREATE TRIGGER in prepared statements and
stored routines.
mysql-test/t/sp-destruct.test:
Update test case (new columns added).
mysql-test/t/sp.test:
Update test case (new columns added).
mysql-test/t/view.test:
Update test.
mysys/charset.c:
Move out-parameter to the end of list.
scripts/mysql_system_tables.sql:
Add new columns to mysql.proc and mysql.event.
scripts/mysql_system_tables_fix.sql:
Add new columns to mysql.proc and mysql.event.
sql/event_data_objects.cc:
Support new attributes for events.
sql/event_data_objects.h:
Support new attributes for events.
sql/event_db_repository.cc:
Support new attributes for events.
sql/event_db_repository.h:
Support new attributes for events.
sql/events.cc:
Add new columns to SHOW CREATE event resultset.
sql/mysql_priv.h:
1. Introduce Object_creation_ctx;
2. Introduce SHOW CREATE TRIGGER;
3. Introduce auxilary functions.
sql/sp.cc:
Add support for new store routines attributes.
sql/sp_head.cc:
Add support for new store routines attributes.
sql/sp_head.h:
Add support for new store routines attributes.
sql/sql_lex.cc:
Generate UTF8-body on parsing/lexing.
sql/sql_lex.h:
1. Generate UTF8-body on parsing/lexing.
2. Introduce SHOW CREATE TRIGGER.
sql/sql_parse.cc:
Introduce SHOW CREATE TRIGGER.
sql/sql_partition.cc:
Update parse_sql().
sql/sql_prepare.cc:
Update parse_sql().
sql/sql_show.cc:
Support new attributes for views
sql/sql_trigger.cc:
Support new attributes for views
sql/sql_trigger.h:
Support new attributes for views
sql/sql_view.cc:
Support new attributes for views
sql/sql_yacc.yy:
1. Add SHOW CREATE TRIGGER statement.
2. Generate UTF8-body for views, stored routines, triggers and events.
sql/table.cc:
Introduce Object_creation_ctx.
sql/table.h:
Introduce Object_creation_ctx.
sql/share/errmsg.txt:
Add new errors.
mysql-test/include/ddl_i18n.check_events.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_sp.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_triggers.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_views.inc:
Aux file for test suite.
mysql-test/include/have_cp1251.inc:
Aux file for test suite.
mysql-test/include/have_cp866.inc:
Aux file for test suite.
mysql-test/include/have_koi8r.inc:
Aux file for test suite.
mysql-test/include/have_utf8.inc:
Aux file for test suite.
mysql-test/r/ddl_i18n_koi8r.result:
Result file.
mysql-test/r/ddl_i18n_utf8.result:
Result file.
mysql-test/r/have_cp1251.require:
Aux file for test suite.
mysql-test/r/have_cp866.require:
Aux file for test suite.
mysql-test/r/have_koi8r.require:
Aux file for test suite.
mysql-test/r/have_utf8.require:
Aux file for test suite.
mysql-test/t/ddl_i18n_koi8r.test:
Complete koi8r test case for the CS patch.
mysql-test/t/ddl_i18n_utf8.test:
Complete utf8 test case for the CS patch.
2007-06-28 21:34:54 +04:00
|
|
|
|
|
|
|
/* End of character ser context. */
|
|
|
|
|
2011-06-10 14:20:15 +07:00
|
|
|
Table_triggers_list(TABLE *table_arg)
|
2024-12-23 21:27:00 +01:00
|
|
|
:record0_field(0), extra_null_bitmap(0), extra_null_bitmap_init(0),
|
|
|
|
record1_field(0), trigger_table(table_arg),
|
2016-10-02 15:35:08 +03:00
|
|
|
m_has_unparseable_trigger(false), count(0)
|
2004-09-07 16:29:46 +04:00
|
|
|
{
|
2016-10-02 15:35:08 +03:00
|
|
|
bzero((char *) triggers, sizeof(triggers));
|
2004-09-07 16:29:46 +04:00
|
|
|
}
|
|
|
|
~Table_triggers_list();
|
|
|
|
|
2021-01-31 18:43:50 +02:00
|
|
|
bool create_trigger(THD *thd, TABLE_LIST *table, String *stmt_query,
|
|
|
|
DDL_LOG_STATE *ddl_log_state,
|
|
|
|
DDL_LOG_STATE *ddl_log_state_tmp_file);
|
2020-12-14 15:57:04 +02:00
|
|
|
bool drop_trigger(THD *thd, TABLE_LIST *table,
|
|
|
|
LEX_CSTRING *sp_name,
|
|
|
|
String *stmt_query, DDL_LOG_STATE *ddl_log_state);
|
2004-09-07 16:29:46 +04:00
|
|
|
bool process_triggers(THD *thd, trg_event_type event,
|
2005-05-24 22:19:33 +04:00
|
|
|
trg_action_time_type time_type,
|
2025-01-24 19:22:02 +07:00
|
|
|
bool old_row_is_record1,
|
2025-01-27 16:29:25 +07:00
|
|
|
bool *skip_row_indicator,
|
2025-01-24 19:22:02 +07:00
|
|
|
List<Item> *fields_in_update_stmt= nullptr);
|
2016-10-02 15:35:08 +03:00
|
|
|
void empty_lists();
|
|
|
|
bool create_lists_needed_for_files(MEM_ROOT *root);
|
2022-10-27 22:18:51 +02:00
|
|
|
bool save_trigger_file(THD *thd, const LEX_CSTRING *db, const LEX_CSTRING *table_name);
|
2004-09-07 16:29:46 +04:00
|
|
|
|
2018-01-07 18:03:44 +02:00
|
|
|
static bool check_n_load(THD *thd, const LEX_CSTRING *db, const LEX_CSTRING *table_name,
|
2022-10-27 22:18:51 +02:00
|
|
|
TABLE *table, bool names_only);
|
2018-01-07 18:03:44 +02:00
|
|
|
static bool drop_all_triggers(THD *thd, const LEX_CSTRING *db,
|
2022-10-27 22:18:51 +02:00
|
|
|
const LEX_CSTRING *table_name, myf MyFlags);
|
2021-03-22 16:05:08 +02:00
|
|
|
static bool prepare_for_rename(THD *thd, TRIGGER_RENAME_PARAM *param,
|
2023-04-26 15:27:01 +04:00
|
|
|
const Lex_ident_db &db,
|
|
|
|
const Lex_ident_table &old_alias,
|
|
|
|
const Lex_ident_table &old_table,
|
|
|
|
const Lex_ident_db &new_db,
|
|
|
|
const Lex_ident_table &new_table);
|
2021-03-22 16:05:08 +02:00
|
|
|
static bool change_table_name(THD *thd, TRIGGER_RENAME_PARAM *param,
|
|
|
|
const LEX_CSTRING *db,
|
2018-01-07 18:03:44 +02:00
|
|
|
const LEX_CSTRING *old_alias,
|
|
|
|
const LEX_CSTRING *old_table,
|
|
|
|
const LEX_CSTRING *new_db,
|
|
|
|
const LEX_CSTRING *new_table);
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
void add_trigger(trg_event_set trg_events,
|
|
|
|
trg_action_time_type action_time,
|
|
|
|
trigger_order_type ordering_clause,
|
|
|
|
const Lex_ident_trigger &anchor_trigger_name,
|
|
|
|
Trigger *trigger);
|
2016-10-02 15:35:08 +03:00
|
|
|
void add_trigger(trg_event_type event_type,
|
|
|
|
trg_action_time_type action_time,
|
|
|
|
trigger_order_type ordering_clause,
|
2023-04-26 15:27:01 +04:00
|
|
|
const Lex_ident_trigger &anchor_trigger_name,
|
2016-10-02 15:35:08 +03:00
|
|
|
Trigger *trigger);
|
|
|
|
Trigger *get_trigger(trg_event_type event_type,
|
|
|
|
trg_action_time_type action_time)
|
|
|
|
{
|
|
|
|
return triggers[event_type][action_time];
|
|
|
|
}
|
|
|
|
/* Simpler version of the above, to avoid casts in the code */
|
|
|
|
Trigger *get_trigger(uint event_type, uint action_time)
|
|
|
|
{
|
|
|
|
return get_trigger((trg_event_type) event_type,
|
|
|
|
(trg_action_time_type) action_time);
|
|
|
|
}
|
|
|
|
|
2007-04-04 12:50:39 +02:00
|
|
|
bool has_triggers(trg_event_type event_type,
|
|
|
|
trg_action_time_type action_time)
|
|
|
|
{
|
2016-10-02 15:35:08 +03:00
|
|
|
return get_trigger(event_type,action_time) != 0;
|
2007-04-04 12:50:39 +02:00
|
|
|
}
|
2004-11-12 17:04:07 +03:00
|
|
|
bool has_delete_triggers()
|
|
|
|
{
|
2016-10-02 15:35:08 +03:00
|
|
|
return (has_triggers(TRG_EVENT_DELETE,TRG_ACTION_BEFORE) ||
|
|
|
|
has_triggers(TRG_EVENT_DELETE,TRG_ACTION_AFTER));
|
2004-11-12 17:04:07 +03:00
|
|
|
}
|
|
|
|
|
2025-01-24 19:22:02 +07:00
|
|
|
bool match_updatable_columns(List<Item> *fields);
|
|
|
|
|
2006-07-06 13:33:23 +04:00
|
|
|
void mark_fields_used(trg_event_type event);
|
2006-07-02 01:51:10 +04:00
|
|
|
|
2011-06-10 10:52:39 +07:00
|
|
|
void set_parse_error_message(char *error_message);
|
|
|
|
|
2004-09-07 16:29:46 +04:00
|
|
|
friend class Item_trigger_field;
|
2009-12-08 17:13:12 +03:00
|
|
|
|
|
|
|
bool add_tables_and_routines_for_triggers(THD *thd,
|
|
|
|
Query_tables_list *prelocking_ctx,
|
|
|
|
TABLE_LIST *table_list);
|
2004-11-24 12:24:02 +03:00
|
|
|
|
2015-11-14 22:51:54 +01:00
|
|
|
Field **nullable_fields() { return record0_field; }
|
2024-12-23 21:27:00 +01:00
|
|
|
void clear_extra_null_bitmap()
|
2015-11-14 22:51:54 +01:00
|
|
|
{
|
2024-12-23 21:27:00 +01:00
|
|
|
if (size_t null_bytes= extra_null_bitmap_init - extra_null_bitmap)
|
|
|
|
bzero(extra_null_bitmap, null_bytes);
|
|
|
|
}
|
|
|
|
void default_extra_null_bitmap()
|
|
|
|
{
|
|
|
|
if (size_t null_bytes= extra_null_bitmap_init - extra_null_bitmap)
|
|
|
|
memcpy(extra_null_bitmap, extra_null_bitmap_init, null_bytes);
|
2015-11-14 22:51:54 +01:00
|
|
|
}
|
|
|
|
|
2017-04-23 19:39:57 +03:00
|
|
|
Trigger *find_trigger(const LEX_CSTRING *name, bool remove_from_list);
|
2016-10-02 15:35:08 +03:00
|
|
|
|
|
|
|
Trigger* for_all_triggers(Triggers_processor func, void *arg);
|
|
|
|
|
2004-11-24 12:24:02 +03:00
|
|
|
private:
|
2015-11-14 22:51:54 +01:00
|
|
|
bool prepare_record_accessors(TABLE *table);
|
2018-01-07 18:03:44 +02:00
|
|
|
Trigger *change_table_name_in_trignames(const LEX_CSTRING *old_db_name,
|
|
|
|
const LEX_CSTRING *new_db_name,
|
|
|
|
const LEX_CSTRING *new_table_name,
|
2016-10-02 15:35:08 +03:00
|
|
|
Trigger *trigger);
|
2006-02-24 23:50:36 +03:00
|
|
|
bool change_table_name_in_triggers(THD *thd,
|
2018-01-07 18:03:44 +02:00
|
|
|
const LEX_CSTRING *old_db_name,
|
|
|
|
const LEX_CSTRING *new_db_name,
|
|
|
|
const LEX_CSTRING *old_table_name,
|
2022-10-27 22:18:51 +02:00
|
|
|
const LEX_CSTRING *new_table_name);
|
2011-06-10 10:52:39 +07:00
|
|
|
|
|
|
|
bool check_for_broken_triggers()
|
|
|
|
{
|
|
|
|
if (m_has_unparseable_trigger)
|
|
|
|
{
|
|
|
|
my_message(ER_PARSE_ERROR, m_parse_error_message, MYF(0));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2023-07-19 17:57:13 +07:00
|
|
|
|
|
|
|
public:
|
|
|
|
TABLE *get_subject_table()
|
|
|
|
{
|
|
|
|
return trigger_table;
|
|
|
|
}
|
2004-09-07 16:29:46 +04:00
|
|
|
};
|
2005-07-19 20:06:49 +04:00
|
|
|
|
2021-03-22 16:05:08 +02:00
|
|
|
|
2007-06-14 19:23:55 +04:00
|
|
|
bool add_table_for_trigger(THD *thd,
|
Patch for the following bugs:
- BUG#11986: Stored routines and triggers can fail if the code
has a non-ascii symbol
- BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
- BUG#19443: INFORMATION_SCHEMA does not support charsets properly
- BUG#21249: Character set of SP-var can be ignored
- BUG#25212: Character set of string constant is ignored (stored routines)
- BUG#25221: Character set of string constant is ignored (triggers)
There were a few general problems that caused these bugs:
1. Character set information of the original (definition) query for views,
triggers, stored routines and events was lost.
2. mysqldump output query in client character set, which can be
inappropriate to encode definition-query.
3. INFORMATION_SCHEMA used strings with mixed encodings to display object
definition;
1. No query-definition-character set.
In order to compile query into execution code, some extra data (such as
environment variables or the database character set) is used. The problem
here was that this context was not preserved. So, on the next load it can
differ from the original one, thus the result will be different.
The context contains the following data:
- client character set;
- connection collation (character set and collation);
- collation of the owner database;
The fix is to store this context and use it each time we parse (compile)
and execute the object (stored routine, trigger, ...).
2. Wrong mysqldump-output.
The original query can contain several encodings (by means of character set
introducers). The problem here was that we tried to convert original query
to the mysqldump-client character set.
Moreover, we stored queries in different character sets for different
objects (views, for one, used UTF8, triggers used original character set).
The solution is
- to store definition queries in the original character set;
- to change SHOW CREATE statement to output definition query in the
binary character set (i.e. without any conversion);
- introduce SHOW CREATE TRIGGER statement;
- to dump special statements to switch the context to the original one
before dumping and restore it afterwards.
Note, in order to preserve the database collation at the creation time,
additional ALTER DATABASE might be used (to temporary switch the database
collation back to the original value). In this case, ALTER DATABASE
privilege will be required. This is a backward-incompatible change.
3. INFORMATION_SCHEMA showed non-UTF8 strings
The fix is to generate UTF8-query during the parsing, store it in the object
and show it in the INFORMATION_SCHEMA.
Basically, the idea is to create a copy of the original query convert it to
UTF8. Character set introducers are removed and all text literals are
converted to UTF8.
This UTF8 query is intended to provide user-readable output. It must not be
used to recreate the object. Specialized SHOW CREATE statements should be
used for this.
The reason for this limitation is the following: the original query can
contain symbols from several character sets (by means of character set
introducers).
Example:
- original query:
CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
- UTF8 query (for INFORMATION_SCHEMA):
CREATE VIEW v1 AS SELECT 'Hello' AS c1;
client/mysqldump.c:
Set original character set and collation before dumping definition query.
include/my_sys.h:
Move out-parameter to the end of list.
mysql-test/lib/mtr_report.pl:
Ignore server-warnings during the test case.
mysql-test/r/create.result:
Update result file.
mysql-test/r/ctype_cp932_binlog_stm.result:
Update result file.
mysql-test/r/events.result:
Update result file.
mysql-test/r/events_bugs.result:
Update result file.
mysql-test/r/events_grant.result:
Update result file.
mysql-test/r/func_in.result:
Update result file.
mysql-test/r/gis.result:
Update result file.
mysql-test/r/grant.result:
Update result file.
mysql-test/r/information_schema.result:
Update result file.
mysql-test/r/information_schema_db.result:
Update result file.
mysql-test/r/lowercase_view.result:
Update result file.
mysql-test/r/mysqldump.result:
Update result file.
mysql-test/r/ndb_sp.result:
Update result file.
mysql-test/r/ps.result:
Update result file.
mysql-test/r/rpl_replicate_do.result:
Update result file.
mysql-test/r/rpl_sp.result:
Update result file.
mysql-test/r/rpl_trigger.result:
Update result file.
mysql-test/r/rpl_view.result:
Update result file.
mysql-test/r/show_check.result:
Update result file.
mysql-test/r/skip_grants.result:
Update result file.
mysql-test/r/sp-destruct.result:
Update result file.
mysql-test/r/sp-error.result:
Update result file.
mysql-test/r/sp-security.result:
Update result file.
mysql-test/r/sp.result:
Update result file.
mysql-test/r/sql_mode.result:
Update result file.
mysql-test/r/system_mysql_db.result:
Update result file.
mysql-test/r/temp_table.result:
Update result file.
mysql-test/r/trigger-compat.result:
Update result file.
mysql-test/r/trigger-grant.result:
Update result file.
mysql-test/r/trigger.result:
Update result file.
mysql-test/r/view.result:
Update result file.
mysql-test/r/view_grant.result:
Update result file.
mysql-test/t/events.test:
Update test case (new columns added).
mysql-test/t/information_schema.test:
Update test case (new columns added).
mysql-test/t/show_check.test:
Test case for SHOW CREATE TRIGGER in prepared statements and
stored routines.
mysql-test/t/sp-destruct.test:
Update test case (new columns added).
mysql-test/t/sp.test:
Update test case (new columns added).
mysql-test/t/view.test:
Update test.
mysys/charset.c:
Move out-parameter to the end of list.
scripts/mysql_system_tables.sql:
Add new columns to mysql.proc and mysql.event.
scripts/mysql_system_tables_fix.sql:
Add new columns to mysql.proc and mysql.event.
sql/event_data_objects.cc:
Support new attributes for events.
sql/event_data_objects.h:
Support new attributes for events.
sql/event_db_repository.cc:
Support new attributes for events.
sql/event_db_repository.h:
Support new attributes for events.
sql/events.cc:
Add new columns to SHOW CREATE event resultset.
sql/mysql_priv.h:
1. Introduce Object_creation_ctx;
2. Introduce SHOW CREATE TRIGGER;
3. Introduce auxilary functions.
sql/sp.cc:
Add support for new store routines attributes.
sql/sp_head.cc:
Add support for new store routines attributes.
sql/sp_head.h:
Add support for new store routines attributes.
sql/sql_lex.cc:
Generate UTF8-body on parsing/lexing.
sql/sql_lex.h:
1. Generate UTF8-body on parsing/lexing.
2. Introduce SHOW CREATE TRIGGER.
sql/sql_parse.cc:
Introduce SHOW CREATE TRIGGER.
sql/sql_partition.cc:
Update parse_sql().
sql/sql_prepare.cc:
Update parse_sql().
sql/sql_show.cc:
Support new attributes for views
sql/sql_trigger.cc:
Support new attributes for views
sql/sql_trigger.h:
Support new attributes for views
sql/sql_view.cc:
Support new attributes for views
sql/sql_yacc.yy:
1. Add SHOW CREATE TRIGGER statement.
2. Generate UTF8-body for views, stored routines, triggers and events.
sql/table.cc:
Introduce Object_creation_ctx.
sql/table.h:
Introduce Object_creation_ctx.
sql/share/errmsg.txt:
Add new errors.
mysql-test/include/ddl_i18n.check_events.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_sp.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_triggers.inc:
Aux file for test suite.
mysql-test/include/ddl_i18n.check_views.inc:
Aux file for test suite.
mysql-test/include/have_cp1251.inc:
Aux file for test suite.
mysql-test/include/have_cp866.inc:
Aux file for test suite.
mysql-test/include/have_koi8r.inc:
Aux file for test suite.
mysql-test/include/have_utf8.inc:
Aux file for test suite.
mysql-test/r/ddl_i18n_koi8r.result:
Result file.
mysql-test/r/ddl_i18n_utf8.result:
Result file.
mysql-test/r/have_cp1251.require:
Aux file for test suite.
mysql-test/r/have_cp866.require:
Aux file for test suite.
mysql-test/r/have_koi8r.require:
Aux file for test suite.
mysql-test/r/have_utf8.require:
Aux file for test suite.
mysql-test/t/ddl_i18n_koi8r.test:
Complete koi8r test case for the CS patch.
mysql-test/t/ddl_i18n_utf8.test:
Complete utf8 test case for the CS patch.
2007-06-28 21:34:54 +04:00
|
|
|
const sp_name *trg_name,
|
2007-06-14 19:23:55 +04:00
|
|
|
bool continue_if_not_exist,
|
|
|
|
TABLE_LIST **table);
|
|
|
|
|
|
|
|
void build_trn_path(THD *thd, const sp_name *trg_name, LEX_STRING *trn_path);
|
|
|
|
|
2018-01-07 18:03:44 +02:00
|
|
|
bool check_trn_exists(const LEX_CSTRING *trn_path);
|
2007-06-14 19:23:55 +04:00
|
|
|
|
|
|
|
bool load_table_name_for_trigger(THD *thd,
|
|
|
|
const sp_name *trg_name,
|
2017-04-23 19:39:57 +03:00
|
|
|
const LEX_CSTRING *trn_path,
|
|
|
|
LEX_CSTRING *tbl_name);
|
2010-03-31 16:05:33 +02:00
|
|
|
bool mysql_create_or_drop_trigger(THD *thd, TABLE_LIST *tables, bool create);
|
2020-12-14 15:57:04 +02:00
|
|
|
bool rm_trigname_file(char *path, const LEX_CSTRING *db,
|
|
|
|
const LEX_CSTRING *trigger_name, myf MyFlags);
|
2010-03-31 16:05:33 +02:00
|
|
|
|
|
|
|
extern const char * const TRG_EXT;
|
|
|
|
extern const char * const TRN_EXT;
|
2007-06-14 19:23:55 +04:00
|
|
|
|
MDEV-10164: Add support for TRIGGERS that fire on multiple events
Added capability to create a trigger associated with several trigger
events. For this goal, the syntax of the CREATE TRIGGER statement
was extended to support the syntax structure { event [ OR ... ] }
for the `trigger_event` clause. Since one trigger will be able to
handle several events it should be provided a way to determine what
kind of event is handled on execution of a trigger. For this goal
support of the clauses INSERTING, UPDATING , DELETING was added by
this patch. These clauses can be used inside a trigger body to detect
what kind of trigger action is currently processed using the following
boilerplate:
IF INSERTING THEN ...
ELSIF UPDATING THEN ...
ELSIF DELETING THEN ...
In case one of the clauses INSERTING, UPDATING, DELETING specified in
a trigger's body not matched with a trigger event type, the error
ER_INCOMPATIBLE_EVENT_FLAG is emitted.
After this patch be pushed, one Trigger object will be associated with
several trigger events. It means that the array
Table_triggers_list::triggers
can contain several pointers to the same Trigger object in array members
corresponding to different events. Moreover, support of several trigger
events for the same trigger requires that the data members `next` and
`action_order` of the Trigger class be converted to arrays to store
relating information per trigger event base.
Ability to specify the same trigger for different event types results in
necessity to handle invalid cases on execution of the multi-event
trigger, when the OLD or NEW qualifiers doesn't match a current event
type against that the trigger is run. The clause OLD should produces
the NULL value for INSERT event, whereas the clause NEW should produce
the NULL value for DELETE event.
2025-04-19 18:36:03 +07:00
|
|
|
extern const LEX_CSTRING trg_event_type_names[];
|
|
|
|
|
2009-09-23 23:32:31 +02:00
|
|
|
#endif /* SQL_TRIGGER_INCLUDED */
|