Event trigger system based on openGauss database and implementation method thereof

Abstract

The invention relates to an event trigger system based on an openGauss database. The system comprises: an event trigger definition module supporting a user to define a trigger rule of an event trigger; the trigger function execution module provides an execution environment for a function associated with the trigger and executes function logic; and the event monitoring and processing module monitors database operation events, matches corresponding event triggers according to trigger rules, and coordinates the execution sequence and error processing of correlation functions of the event triggers. According to the system, flexible trigger rule definition is supported through extension grammar, the metadata management efficiency is guaranteed by combining semantic verification and a special storage structure, the execution performance is optimized by utilizing pre-compiling and caching technologies, accurate monitoring and trigger coordination of events are realized through a kernel hook mechanism, and the reliability of the system is improved. The limitation that a traditional trigger only covers a DML event is effectively solved, the reliable management and control capability of full-type operation (DML / DDL) is provided for the openGauss database, and the safety, maintainability and application stability of the database are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database operation, in particular to an event trigger system based on an openGauss database and an implementation method thereof. BACKGROUND

[0002] In the field of database management systems (DBMS), triggers are a special class of database objects designed to automatically respond and control data operations through a mechanism bound to table events. Specifically, triggers are essentially stored procedures, but their execution is not explicitly invoked by users, but triggered by specific database events such as data insertion, update or deletion operations. This feature plays a key role in maintaining data integrity, implementing business rule constraints, and performing audit logging, effectively improving the reliability and application stability of the database system. For example, when a user performs an INSERT, UPDATE or DELETE data manipulation language (DML) command on a table, triggers can automatically perform associated operations (such as cascading updates to associated table data), prevent illegal data modifications (such as rollback of illegal operations after checking business rules), or record operation logs (such as tracking changes to sensitive data), thereby significantly simplifying the data operation logic of the application layer, improving development efficiency, and reducing the risk of data inconsistency caused by human error. In the openGauss database system, the design and implementation of triggers closely follow the execution scenario of DML commands, providing flexible event response capabilities for table insert, delete and modify operations.

[0003] It is worth noting that the operation types of the database system are not limited to DML commands, but also include data definition language (DDL) commands (such as creating / modifying table structures, index operations, etc.) and other management commands. Although DDL commands do not directly manipulate row data in tables, their execution can have a significant impact on the overall structure or metadata state of the database (such as deleting table structures may result in loss of associated data). In existing technologies, for such non-table event-related database operations (such as DDL commands), the existing trigger system has limitations in coverage and response mechanisms, making it difficult to fully guarantee the reliability and security of database operations. Therefore, there is an urgent need for an event trigger system that can expand the scope of triggers, covering more types of database operations, to improve the operation control capabilities throughout the life cycle of the database. SUMMARY

[0004] In order to solve the above problems, the application provides a new event trigger system based on an openGauss database. The event trigger system can efficiently monitor, intercept and automatically process specific database events (especially DDL events) in the openGauss database, thereby enhancing the security, manageability and operation efficiency of the openGauss database.

[0005] In summary, the application provides an event trigger system based on an openGauss database. Through modular architecture design and multi-level technical optimization, flexible response and precise control of database operation events (including DML and DDL) are achieved, significantly improving the reliability, security and manageability of database operations. The event trigger system mainly consists of an event trigger definition module, a trigger function execution module and an event monitoring and processing module.

[0006] Specifically, the application provides the following technical solutions: The first aspect of the application provides an event trigger system based on an openGauss database, which includes an event trigger definition module, a trigger function execution module and an event monitoring and processing module. Wherein: The event trigger definition module is used to extend the original syntax of the database and support user-defined trigger rules of the event trigger, which includes trigger event type, trigger timing and trigger condition; The trigger function execution module is used to provide an execution environment for the functions associated with the trigger and execute the function logic; The event monitoring and processing module is used to monitor database operation events, match corresponding event triggers according to trigger rules, and coordinate the execution order and error handling of associated functions.

[0007] Further, in the event trigger system of the application, the event trigger definition module includes: A syntax parsing unit is used to parse the extended syntax definition statement input by the user, and decompose the statement into syntax units of trigger name, trigger event type, trigger condition clause and associated function name; A semantic verification unit is used to verify the legality of the syntax units, including verifying the uniqueness and naming specification of the trigger name, the system support of the trigger event type, the definition legality and data type compatibility of the variables in the trigger condition, the existence of the associated function and the return type conforming to the preset interface specification; A metadata storage unit is configured to store the trigger metadata that passes the check in a system table (which is indexed for the trigger event type to improve query efficiency), and the metadata includes the unique identifier of the trigger, the trigger event type (stored in an enumeration type), the trigger condition expression, and the system table identifier of the associated function.

[0008] Further, in the event trigger system of the present application, the trigger function execution module includes: A context packaging unit is configured to set a dedicated execution context for the function associated with the trigger, and pass the metadata of the trigger event to the function through a system interface, wherein the metadata includes the event type, the database object information involved, the operation user information, and the timestamp. A performance optimization unit is configured to optimize the function execution logic of high-frequency triggers, including: pre-compiling and caching the query plan of the SQL operation (such as log table insertion) dependent on the function, and performing in-memory caching on the read-only data (such as system table metadata) frequently accessed during function execution to reduce disk I / O.

[0009] Further, in the event trigger system of the present application, the event listening and processing module includes: An event hook registration unit is configured to register an event hook function corresponding to a database operation event (such as DDL_COMMAND_START and TABLE_REWRITE) with the kernel during the startup phase of the database. A trigger matching unit is configured to, when the event hook function is triggered, acquire a list of all event triggers that meet the conditions by querying the event trigger system table (based on the trigger event type index), and sort the event triggers in alphabetical order according to the names. An execution coordination unit is configured to execute the associated functions of the sorted triggers in sequence, terminate the execution of subsequent functions if a function execution returns an error, and decide whether to continue executing the original database operation according to a preset strategy (such as rolling back the original operation or recording error logs).

[0010] Further, in the event trigger system of the present application, the trigger event type includes operation events of DML commands (such as INSERT, UPDATE, and DELETE) and DDL commands (such as CREATE TABLE, ALTER TABLE, and DROP TABLE). The trigger condition clause supports filtering rules based on event attributes, including limiting the triggering of DDL operations to only specific schemas or objects.

[0011] The second aspect of the present application provides an implementation method of an event trigger based on an openGauss database, including the following steps: S1. Defining a trigger rule of an event trigger by an event trigger definition module, the trigger rule comprising a trigger event type, a trigger timing and a trigger condition; S2. Setting an execution environment for a function associated with the trigger by a trigger function execution module, and executing function logic; S3. Listening to a database operation event by an event listening and processing module, matching a corresponding event trigger according to a trigger rule, and coordinating an execution order and an error processing of a function associated with the trigger.

[0012] Further, in the implementation method of the event trigger, step S1 specifically comprises: S11. A user inputs an extended syntax definition statement (such as a CREATE EVENT TRIGGER statement), declares a trigger event type (such as DDL_COMMAND_START), a trigger timing (BEFORE / AFTER / INSTEADOF) and a trigger condition clause; S12. A syntax parsing unit performs lexical and syntax analysis on the statement, and decomposes the statement into syntax units of a trigger name, a trigger event type, a trigger condition clause and an associated function name; S13. A semantic verification unit performs legality verification on the syntax units, including uniqueness of a trigger name, support of a trigger event type, legality of a trigger condition variable and conformity of an associated function interface; S14. After verification, a metadata storage unit stores trigger metadata in a system table, and the system table is indexed according to a trigger event type.

[0013] Further, in the implementation method of the event trigger, step S2 specifically comprises: S21. When a trigger function is executed, a context encapsulation unit sets a special execution context for the trigger function, and passes event metadata (such as a DDL command text, an involved object name and operation user information); S22. A performance optimization unit precompiles a high-frequency trigger function SQL operation (such as a log table insertion) to generate a persistent query plan, and caches in memory system table metadata frequently accessed in function execution, thereby reducing disk I / O.

[0014] Further, in the implementation method of the event trigger, step S3 specifically comprises: S31. When a database is started, an event hook registration unit registers an event hook function (such as ddl_command_start_hook) to a kernel; S32. When a specific event (such as DDL_COMMAND_START) occurs, the kernel triggers the corresponding hook function, which queries the event trigger system table (based on the trigger event type index) to obtain the trigger list that meets the conditions, and sorts them in alphabetical order by name; S33. The execution coordination unit sequentially executes the sorted trigger associated functions: if a function returns an error, it terminates the execution of subsequent functions, and decides whether to continue executing the original database operation according to the preset strategy (such as rolling back the original operation, recording error logs).

[0015] The third aspect of the present application provides an electronic device, comprising: a memory and a processor; The memory is used for storing a computer program; The processor is used for executing the computer program to realize the steps of the event trigger implementation method based on the openGauss database.

[0016] In summary, the event trigger system based on the openGauss database proposed in the present application covers all types of database operations such as DDL by extending the trigger function, and achieves the following technical effects: (1) Enhance database security: The system supports triggering an interception check mechanism before performing dangerous DDL operations (such as DROP TABLE, TRUNCATE TABLE, etc.), and verifies the legality of the operation (such as checking the operation role permission, environmental conditions, etc.) through predefined trigger conditions and security policies, which can effectively prevent data loss, leakage and other risks caused by misoperation or malicious operation, and improve the security protection capability of the database.

[0017] (2) Improve database management efficiency: The system can automatically trigger auxiliary operations associated with database schema changes (such as automatically generating necessary indexes after creating a new table, setting default permissions; synchronously updating data dictionary and documents after modifying table structure), reducing the workload of manual intervention by database administrators, reducing operation delays or errors caused by human negligence, and significantly improving the automation level and management efficiency of database routine operation and maintenance.

[0018] (3) Achieve comprehensive audit and log recording: The system can record the full process information of database schema changes (including operation timestamp, operation user identity, specific DDL command content, involved target objects and pre-change and post-change state, etc.) through trigger functions, providing a high-reliability data source for database audit, supporting historical change traceability, problem root cause analysis and compliance requirement satisfaction, and strengthening the transparency and traceability of database operation.

[0019] Other features and advantages of the present application will be set forth in the following description of the application, taken in conjunction with the accompanying drawings and the appended claims. The features and advantages of the present application will become better understood with reference to the detailed description and drawings, wherein: BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings involved in the embodiment description will be briefly introduced below. It should be pointed out that the drawings only show some embodiments of the present application. For those skilled in the art, other related drawings can be derived from these drawings without creative labor.

[0021] Figure 1 The constituent structure diagram of the event trigger system of the present application based on openGauss database.

[0022] Figure 2 The implementation method diagram of the event trigger of the present application.

[0023] Figure 3 The running flowchart of the event trigger system of the present application.

[0024] Figure 4 The structural schematic diagram of the electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solutions and advantages of the embodiments of the present application more clear and obvious, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be pointed out that the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0026] In this document, the term “comprising” and any form of the word “comprise”, such as “comprise”, “comprises” and “comprising”, are open-ended language that should be interpreted to mean “including but not limited to”, that is, the enumerated content is not exhaustive, and other content not explicitly mentioned can also be included. The term “based on” should be understood as “at least partially based on”, that is, the basis or condition referred to can not be the only factor, and other related factors can also be involved. The term “one embodiment” should be understood as “at least one embodiment”, that is, the described embodiment is not the only possible implementation, and other similar embodiments can also exist.

[0027] In the present application, the terms "one" and "multiple" used to modify the relevant elements or features are illustrative rather than restrictive. Unless explicitly stated otherwise in the context, "one" should be understood as "at least one" and "multiple" should be understood as "at least two". Those skilled in the art should reasonably interpret these terms according to the semantics and logical relationship of the context, ensuring that they cover the possibility of "one or more".

[0028] Embodiment 1: An event trigger system based on openGauss database The present application proposes an event trigger system (ETS) for openGauss database. The system captures, analyzes, schedules and executes DDL and specific database-level events in a kernel-level extension manner, thereby providing a unified event response framework for metadata changes without affecting the DML trigger mechanism. The event trigger system of the present application is composed of an event trigger definition module, a trigger function execution module and an event listening and processing module, and a multi-level optimization mechanism is designed inside each module. The specific technical solutions are as follows: I. System architecture design The present system adopts a layered decoupled modular architecture. Through the definition module, flexible configuration of trigger rules is achieved. The execution module ensures efficient operation of trigger logic. The listening and processing module completes accurate matching of events and triggers. The three work together to form a complete event trigger closed loop, covering the control requirements of the whole life cycle of database operations.

[0029] II. Core module design Figure 1 ) 1. Event trigger definition module: rule configuration and syntax semantic verification This module supports users to define the type of trigger event, trigger timing (such as BEFORE at the beginning of the event, AFTER after the successful execution of the event, INSTEAD OF instead of the original event) and trigger conditions by extending the original database syntax. The specific implementation includes: (1) Syntax extension and parsing: Add event trigger definition syntax (such as CREATE EVENT TRIGGER statement), allow users to explicitly declare trigger event type (such as DDL_COMMAND_START, DDL_COMMAND_END, TABLE_REWRITE, SQL_DROP, etc.), trigger timing (BEFORE, AFTER, INSTEAD OF), trigger condition expression and associated function identifier. Syntax parser based on the extended syntax rules for user input lexical, syntax analysis, the definition of the statement into a structured syntax unit (including trigger name, event type, trigger condition, associated function name, etc.).

[0030] (2) Semantic checking and storage: Through the semantic checking module (semantic checker) to the parsed syntax unit for multi-dimensional verification, including: Naming specification verification: Ensure that the trigger name is unique and conforms to the database object naming rules (such as no duplicate, character set method, length limit, etc.); Event type legality verification: Verify whether the trigger event type is a system pre-defined or extended supported type (such as DDL_COMMAND_END, SQL_DROP, etc.); Condition and function validity verification: Check whether the variables in the trigger condition are defined in the current database environment and the data type is compatible with the operator, confirm the existence of the associated function and the return type is event_trigger (ensure that the function meets the trigger execution interface specification).

[0031] After the above verification, the system will store the trigger metadata (unique identifier, name, event type, trigger condition expression, associated function identifier, etc.) in a specially designed system table. The table uses an enumerated type field to store the event type (such as EVENT_TYPE_ENUM), and establishes an index for the trigger event type field to improve the subsequent query efficiency.

[0032] Further, in the database system table, a storage structure is specially designed for event triggers. In the system table, each row records the relevant information of an event trigger, including the unique identifier of the trigger (used for quickly locating and referencing the trigger within the system), the trigger name, the trigger event type (stored using an enumeration type, for example, DDL_COMMAND_START, DDL_COMMAND_END, TABLE_REWRITE, and SQL_DROP correspond to ddl_command_start, ddl_command_end, table_rewrite, and sql_drop events, respectively), the trigger condition expression (if any), and the identifier of the associated function (pointing to the corresponding record in the system table storing the function definition). The above storage structure design facilitates the efficient querying and management of event trigger information by the database management system.

[0033] 2. Trigger function execution module: logic running and performance optimization This module is responsible for the execution environment setup, logic running, and performance optimization of the trigger associated functions. The function development specification and execution mechanism associated with the event trigger are developed, and these functions can access detailed information related to the trigger event, including the executed DDL command content (for example, a function is defined for recording DDL operation logs), the object name involved, the schema to which it belongs, etc. Specifically, it includes: (1) Context environment encapsulation: a dedicated execution context is set for the trigger function, and the detailed metadata of the trigger event (such as the DDL command text, the object name / schema involved, the operation user information, the event timestamp, etc.) is passed to the function through the system interface, ensuring that the function can execute logic based on complete event information (such as log recording, data verification, or operation interception).

[0034] (2) Execution efficiency optimization: Pre-compilation technology: for frequently triggered functions (such as DDL log recording functions), the SQL operations (such as log table insertion statements) they depend on are pre-compiled to generate persistent query plans. When the function is called multiple times, the pre-compiled plan is directly reused to avoid repeated parsing and optimization overhead, significantly improving execution speed.

[0035] Cache mechanism: for read-only data frequently accessed in function execution (such as database configuration parameters, system table metadata), an in-memory caching strategy is adopted. For example, when the function needs to obtain schema permission information, the result is cached after the first query, and subsequent calls directly read from the cache, reducing disk I / O times and system load.

[0036] 3. Event listening and processing module: event sensing and trigger coordination The module realizes the listening to specific events through the kernel-level event hook mechanism, and coordinates the in-order execution of the trigger, specifically including: (1) Event hook registration and listening: during the startup phase of the openGauss database, an event hook function related to the event trigger is registered to the kernel (for example, for the ddl_command_start event, a ddl_command_start_hook hook function is registered, which is called before each DDL command execution). When a specific event (such as before DDL command execution) occurs, the kernel automatically triggers the corresponding hook function to start the trigger matching process.

[0037] (2) Trigger matching and execution: after the hook function is triggered, the system queries the event trigger system table (in order to improve query efficiency, appropriate indexes are established on the system table, such as indexes based on trigger event types, to quickly locate the trigger records related to specific events) to obtain a list of all triggers that meet the current event. When the relevant trigger is found, its associated function is executed in alphabetical order according to the trigger name.

[0038] (3) Sequential execution and error handling: during the function execution process, if a trigger function execution returns an error (such as a verification failure), the system immediately terminates the execution of subsequent triggers, and decides whether to continue executing the original database operation according to the preset strategy (such as rolling back the original DDL command, recording error logs).

[0039] (4) High-concurrency protection: through transaction isolation and resource lock mechanisms (such as row locks and semaphores), it is ensured that the trigger execution in high-concurrency scenarios will not cause deadlocks or performance bottlenecks, balancing reliability and throughput.

[0040] In summary, the system supports flexible trigger rule definition by extending the syntax, guarantees metadata management efficiency through semantic verification and special storage structure, optimizes execution performance using pre-compilation and caching technology, and realizes precise event listening and trigger coordination through the kernel hook mechanism, effectively solving the limitations of traditional triggers that only cover DML events, providing reliable control capabilities for openGauss databases for all types of operations (DML / DDL), and significantly improving the security, maintainability and application stability of the database.

[0041] As shown in Figure 2 , the implementation method of the event trigger based on the openGauss database comprises the following steps: S1. Defining the trigger rules of the event trigger through the event trigger definition module, the trigger rules including the trigger event type, the trigger timing and the trigger condition; S2. Set up the execution environment for the function associated with the trigger through the trigger function execution module, and execute the function logic; S3. Monitor database operation events through the event listening and handling module, match the corresponding event triggers according to the triggering rules, and coordinate the execution order and error handling of their associated functions.

[0042] Example 2: Preventing Unauthorized Table Deletion Operations Create an event trigger function: In the above embodiment, when any deletion operation occurs, an event trigger is activated. Its associated function checks whether the object to be deleted is a table and determines whether the user currently performing the operation has permission to delete the schema containing that table. If the user does not have permission, an exception is thrown to prevent the deletion operation.

[0043] Example 3: Automatically adding indexes to newly created tables Create an event trigger function: In the above embodiment, after each execution of the CREATE TABLE command, the event trigger is activated. The associated function obtains the relevant information about the table creation from the og_event_trigger_ddl_commands() function, and then automatically adds an index to the specified column of the newly created table to improve the table's query performance.

[0044] Example 4: Implementation Process Figure 3 The diagram illustrates the core flow of the event trigger system of this invention, which performs event listening, condition judgment, function execution, and command processing, including the following steps: Step 1: Database operation capture and type determination When a database operation occurs, first determine the operation type: If it is a DDL operation (Data Definition Language operation), proceed to step 2; If it is a non-DDL operation, proceed directly to step 5, "Execute the original command".

[0045] Step 2: Verify the trigger definition for DDL operations Check for the existence of a matching event trigger definition for the DDL operation: If no relevant trigger definition exists, proceed to step 5; If a matching trigger definition exists, proceed to step 3.

[0046] Step 3: Trigger functions are executed sequentially. Execute the matched trigger function one by one in the preset order: Call the first trigger function; After execution is completed, go to step 4 to judge the execution result and the subsequent process.

[0047] Step 4: Trigger function execution state processing Process the execution result of the current trigger function: If the execution is error-free: judge whether there is a next trigger function: If yes, return to step 3 to execute the next function; If no, go to step 5; If an error occurs in execution: stop the execution of the subsequent trigger function, process the original command according to the pre-defined strategy (such as rollback, log recording), and skip step 5 to complete the exception processing directly.

[0048] Step 5: Original command execution Whether or not after trigger processing, finally execute the original database command: When trigger processing is successful or there is no trigger, execute the original command directly; When trigger processing fails, execute the original command according to the error handling strategy (such as blocking, degraded execution).

[0049] The flowcharts and block diagrams in the drawings show possible implementation manners of systems, methods and computer program products according to various embodiments of the present application, including architecture, function and operation. In these drawings, each block can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should be noted that each block in the block diagram and / or flowchart and the combination of these blocks can use a dedicated hardware-based system to implement the specified function or operation, or a combination of dedicated hardware and computer instructions.

[0050] As shown in Figure 4 The embodiments of the present application also disclose an electronic device, which comprises a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. Wherein the processor 310, the communication interface 320 and the memory 330 complete the communication among each other through the communication bus 340. The processor 310 realizes the steps of the implementation method of the event trigger based on the openGauss database by running the executable computer program.

[0051] It is understood that the electronic device, in addition to including the memory and the processor, can also contain input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through an I / O interface (i.e., an input / output interface).

[0052] The operations of the present application can be implemented by using one or more program design languages or combinations thereof to write computer program codes. The program design languages include, but are not limited to, the following types: Object-oriented program design languages, such as Java, Smalltalk, C++, etc. Conventional procedural program design languages, such as the "C" language or similar program design languages.

[0053] The execution of the program code includes, but is not limited to: Completely on a user computer; Partially on a user computer and partially on a remote computer; As a separate software package; Completely on a remote computer or server.

[0054] In scenarios involving remote computers, the remote computers can be connected to the user computer through any type of network, including but not limited to a local area network (LAN) or a wide area network (WAN). In addition, the remote computer can also be connected to an external computer through an Internet service provider, such as through the Internet.

[0055] Further, the present application also discloses a computer-readable storage medium, when the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device can perform each step of the implementation method of the event trigger based on the openGauss database disclosed in the present application.

[0056] In the context of the present application, a computer-readable storage medium refers to a tangible medium capable of storing computer program codes and related data. Specific examples include, but are not limited to, the following: (1) Portable computer disk: such as a removable magnetic storage medium such as a floppy disk.

[0057] (2) Hard disk: including fixed storage devices such as mechanical hard disks and solid state disks.

[0058] (3) Random Access Memory (RAM): a volatile storage medium used for temporary storage of data and program codes.

[0059] (4) Read-Only Memory (ROM): Non-volatile storage medium for storing fixed programs and data.

[0060] (5) Erasable Programmable Read-Only Memory (EPROM) or Flash Memory: Non-volatile storage medium that supports multiple erasing and programming.

[0061] (6) Optical Fiber Storage Device: Storage medium based on fiber optic technology.

[0062] (7) Portable Compact Disc Read-Only Memory (CD-ROM): Read-only medium that stores data in the form of optical discs.

[0063] (8) Optical Storage Device: Storage medium based on optical principles such as DVD, Blu-ray Disc, etc.

[0064] (9) Magnetic Storage Device: Storage medium based on magnetic principles such as magnetic tape, magnetic disk, etc.

[0065] (10) Any suitable combination of the above: For example, a combination of multiple storage media is used to meet different storage needs.

[0066] These computer-readable storage media can be used to store the program code and related data described in this application to support the running of programs and the persistent storage of data.

[0067] In particular, according to the embodiments of the present application, the processes described in the flowcharts can be implemented as a computer software program. For example, the embodiments of the present application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. The computer program contains program code for executing the implementation method of the event trigger based on the openGauss database disclosed in this application. When the computer program is executed by a processing device, the above-mentioned functions defined in the embodiments of the present application can be realized.

[0068] Although the above discussion contains several specific implementation details, these details should not be interpreted as limiting the scope of the present application. The above description is only a preferred embodiment of the present application and an explanation of the principles of technology used. Those skilled in the art should understand that the scope of the disclosure involved in the present application is not limited to the technical solutions formed by the specific combination of the above technical features. At the same time, the present application should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept.

[0069] Those skilled in the art should understand that they can make modifications to the technical solutions recorded in the foregoing embodiments, or make equivalent replacements to some of the technical features without departing from the spirit and scope of the technical solutions of the embodiments of the present application. The modifications or replacements will not cause the nature of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An event trigger system based on the openGauss database, characterized in that, The event trigger system includes an event trigger definition module, a trigger function execution module, and an event listening and processing module; wherein: The event trigger definition module is used to extend the native syntax of the database and supports user-defined triggering rules for event triggers. The triggering rules include the trigger event type, triggering timing, and triggering conditions. The trigger function execution module is used to provide an execution environment for the function associated with the trigger and to execute the function logic; The event listening and processing module is used to listen for database operation events, match the corresponding event triggers according to the triggering rules, and coordinate the execution order and error handling of their associated functions.

2. The event trigger system according to claim 1, characterized in that, The event trigger definition module includes: The syntax parsing unit is used to parse the extended syntax definition statement input by the user, and decompose the statement into syntax units of trigger name, trigger event type, trigger condition clause and associated function name; The semantic verification unit is used to verify the legality of the syntax unit, including verifying the uniqueness and naming convention of the trigger name, the system support of the trigger event type, the legality of the variable definition in the trigger condition and the data type compatibility, and the existence and return type of the associated function conforming to the preset interface specification. The metadata storage unit is used to store the metadata of the verified triggers in the system table. The metadata includes the trigger's unique identifier, trigger event type, trigger condition expression, and system table identifier of the associated function.

3. The event trigger system according to claim 1, characterized in that, The trigger function execution module includes: The context encapsulation unit is used to set a dedicated execution context for the function associated with the trigger and to pass the metadata of the triggering event to the function through the system interface. The metadata includes the event type, information of the database objects involved, information of the user who operated, and timestamp. The performance optimization unit is used to optimize the execution logic of frequently triggered functions, including: pre-compiling and caching query plans for SQL operations that depend on functions, and caching read-only data that is frequently accessed during function execution in memory to reduce disk I / O.

4. The event trigger system according to claim 1, characterized in that, The event listening and processing module includes: An event hook registration unit is used to register event hook functions with the kernel during the database startup phase. The event hook functions correspond to database operation events. The trigger matching unit is used to retrieve a list of all event triggers that meet the criteria by querying the event trigger system table when the event hook function is triggered, and sort them in alphabetical order by name; The execution coordination unit is used to execute the sorted trigger association functions sequentially. If a function returns an error, the execution of subsequent functions is terminated, and a decision is made on whether to continue executing the original database operation based on a preset strategy.

5. The event trigger system according to claim 1, characterized in that, The triggering event types include operation events for DML commands and DDL commands; The trigger condition clause supports filtering rules based on event attributes, including restricting triggering to DDL operations only for specific patterns or objects.

6. A method for implementing an event trigger based on the openGauss database, characterized in that, Includes the following steps: S1. Define the triggering rules of the event trigger through the event trigger definition module. The triggering rules include the triggering event type, triggering timing, and triggering conditions. S2. Set up the execution environment for the function associated with the trigger through the trigger function execution module, and execute the function logic; S3. Monitor database operation events through the event listening and handling module, match the corresponding event triggers according to the triggering rules, and coordinate the execution order and error handling of their associated functions.

7. The method for implementing an event trigger according to claim 6, characterized in that, Step S1 specifically includes: S11. User input extended syntax definition statement, declaring the trigger event type, trigger timing, and trigger condition clause; S12. The syntax parsing unit performs lexical and syntactic analysis on the statement, decomposing it into syntax units of trigger name, trigger event type, trigger condition clause and associated function name; S13. The semantic verification unit performs legality verification on the syntax unit, including the uniqueness of the trigger name, the support of the trigger event type, the legality of the trigger condition variable, and the conformity of the associated function interface; S14. After the verification is successful, the metadata storage unit stores the trigger metadata in the system table, which is indexed for the trigger event type.

8. The method for implementing an event trigger according to claim 6, characterized in that, Step S2 specifically includes: S21. When the trigger function is executed, the context encapsulation unit sets up a dedicated execution context for it and passes event metadata; S22. The performance optimization unit pre-compiles the SQL operations of frequently triggered functions to generate persistent query plans; it also caches frequently accessed system table metadata in memory to reduce disk I / O.

9. The method for implementing an event trigger according to claim 6, characterized in that, Step S3 specifically includes: S31. When the database starts, the event hook registration unit registers event hook functions with the kernel; S32. When a specific event occurs, the kernel triggers the corresponding hook function. The hook function queries the event trigger system table to obtain a list of triggers that meet the conditions and sorts them in alphabetical order by name. S33. The execution coordination unit executes the sorted trigger association functions in sequence: if a function returns an error, the execution of subsequent functions is terminated, and a decision is made on whether to continue executing the original database operation according to a preset strategy.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the method for implementing an event trigger based on the openGauss database as described in any one of claims 6-9.

Images