A database dialect transaction semantic compatibility method, device and medium

Abstract

This specification discloses a database dialect transaction semantic compatibility method, device, and medium, relating to the field of database technology. The method includes: extracting the dialect type of the source database corresponding to the client; writing the globally unified configuration flag corresponding to the dialect type into the current session memory context; and initializing a dialect-compatible session context according to the globally unified configuration flag. The dialect-compatible session context includes the dialect type and a transaction protection switch. Based on the dialect type in the dialect-compatible session context, a dialect-adapted standardized execution plan is generated. When the transaction protection switch indicates that the current session is in dialect-compatible mode, an internal sub-transaction is created as the corresponding current micro-savepoint before the target statement is executed. The encapsulated standard executor function is executed through an exception handling block, and the current micro-savepoint is merged or rolled back in response to the successful or failed execution status of the standard executor function, so as to achieve statement-level atomic lifecycle management.

Description

Technical Field

[0001] This specification relates to the field of database technology, and in particular to a database dialect transaction semantic compatibility method, device and medium. Background Technology

[0002] Against the backdrop of the localization and open-source evolution of information systems, migrating business systems from traditional commercial heterogeneous relational databases (such as Oracle and Microsoft SQL Server) to open-source relational databases (such as PostgreSQL) has become an important trend in data architecture evolution. However, different database management systems have fundamental differences in the semantics of underlying transaction exception handling. Taking statement-level error handling in transactions as an example, databases such as Oracle use a statement-level rollback mechanism. When a single Data Manipulation Language (DML) statement fails to execute (such as violating a unique constraint), the system automatically triggers an implicit savepoint, rolling back only the current statement. The entire transaction remains active, and subsequent statements can continue to execute and eventually commit. In contrast, databases such as PostgreSQL use a transaction-level rollback mechanism. Any statement-level error immediately marks the top-level transaction as aborted, the engine refuses to execute any subsequent instructions, and forces a global rollback. This semantic gap causes complex business logic migrated from Oracle to PostgreSQL (especially stored procedures containing exception handling blocks) to crash globally due to local errors during execution, resulting in business interruption.

[0003] To achieve compatibility between heterogeneous databases, existing technologies have mainly explored the following four solutions. The first is a compatibility device based on static reconstruction and dual-parser isolation (represented by IvorySQL). This uses an independent dialect parser to handle heterogeneous syntax, but it only operates at the parsing layer and does not intervene in the underlying transaction manager state machine, resulting in a lack of transaction semantic penetration and an inability to achieve statement-level rollback compatibility. The second is a protocol compatibility device based on hard-coded parser modification (represented by Babelfish). This deeply intrudes into the PostgreSQL kernel, directly modifying the syntax parser source code. While it can achieve partial semantic compatibility, it is prone to compile-level parsing conflicts, leading to decreased system stability and an inability to smoothly upgrade with community versions as a standard plugin. The third is a statement-level rollback method based on client-side or middleware simulation. This explicitly sends savepoint creation and release commands before and after each business SQL statement. While it can simulate statement-level rollback, it generates a large number of additional network round trips, significantly reducing system throughput. Furthermore, since the PostgreSQL kernel's shared memory can only efficiently cache a limited number of unreleased sub-transactions, the accumulated explicit savepoints in long transactions are prone to triggering sub-transaction overflows, leading to disk overflow penalties and replication delays. The fourth type is the statement-level rollback method based on server-side extension level (represented by pg_statement_rollback). It registers executor hooks on the server side and implicitly injects savepoints through the internal application interface, avoiding network round-trip overhead. However, it lacks a dialect context awareness mechanism, introduces unnecessary execution overhead to native sessions that do not require compatibility, and does not design an active resolution strategy for sub-transactions. In scenarios with long transactions and high-frequency data manipulation languages, sub-transaction identifiers will still accumulate in shared memory for a long time, which also faces the risk of overflow.

[0004] In summary, during the cross-platform migration or heterogeneous application compatibility resolution of heterogeneous relational databases to target open-source relational databases, the semantic differences in transaction exception handling of the underlying database engines can lead to issues such as global transaction crashes and business logic interruptions. Summary of the Invention

[0005] This specification provides one or more embodiments of a database dialect transaction semantic compatibility method, device, and medium to solve the following technical problem: during the cross-platform migration or heterogeneous application compatibility resolution of a heterogeneous relational database to a target open-source relational database, the semantic differences in transaction exception handling of the underlying database engine lead to the problem of global transaction crash and business logic interruption.

[0006] One or more embodiments of this specification employ the following technical solutions: This specification provides one or more embodiments of a database dialect transaction semantic compatibility method. The method includes: obtaining handshake messages during the connection establishment process between a client and a target database; extracting the dialect type of the source database corresponding to the client; writing a globally unified configuration flag corresponding to the dialect type into the current session memory context; and initializing a dialect-compatible session context according to the globally unified configuration flag, wherein the dialect-compatible session context includes a dialect type and a transaction protection switch; receiving a raw SQL string sent by the client; performing multi-dimensional processing on the raw SQL string according to the dialect type in the dialect-compatible session context to generate a dialect-adapted standardized execution plan; obtaining the transaction protection switch in the dialect-compatible session context; when the transaction protection switch indicates that the current session is in dialect-compatible mode, before the target statement in the standardized execution plan is executed, calling the transaction manager interface of the target database to create an internal sub-transaction as the corresponding current micro-savepoint; executing a standard executor function encapsulated through an exception handling block; and merging or rolling back the current micro-savepoint in response to the successful or failed execution status of the standard executor function to achieve statement-level atomic lifecycle management.

[0007] This specification provides one or more embodiments of a database dialect transaction semantics compatible device, including: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the above-described method.

[0008] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions configured to perform the above-described method.

[0009] The above-described at least one technical solution used in the embodiments of this specification can achieve the following beneficial effects: By establishing a dialect-compatible session context that includes dialect type and transaction protection switches during the connection handshake phase, subsequent processing can be aware of the dialect pattern of the current session, avoiding unnecessary overhead to the native session. Based on this, the original structured query language is processed in multiple dimensions according to the dialect type to generate a standardized execution plan. At the executor lifecycle nodes, internal sub-transactions are conditionally created as micro-savepoints based on the transaction protection switches, and statement-level atomic lifecycle management is achieved through exception handling blocks. This method is implemented as a server-side plugin, requiring no modification to the target database kernel source code, adding no network round trips to the client, and binding transaction protection with dialect awareness, achieving high-fidelity compatibility with heterogeneous database transaction semantics. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating a database dialect transaction semantic compatibility method provided in the embodiments of this specification; Figure 2 A schematic diagram of the system architecture of a database dialect transaction semantic compatibility system provided in the embodiments of this specification; Figure 3 This is a schematic diagram of the structure of a database dialect transaction semantic compatibility device provided in the embodiments of this specification. Detailed Implementation

[0011] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0012] This specification provides a database dialect transaction semantic compatibility method. It should be noted that the execution subject in this specification embodiment can be a server or any device with data processing capabilities. Figure 1 This is a flowchart illustrating a database dialect transaction semantic compatibility method provided in an embodiment of this specification, as shown below. Figure 1 As shown, the main steps include the following: Step S101: Obtain the handshake message during the connection establishment process between the client and the target database, extract the dialect type of the source database corresponding to the client, write the global unified configuration flag corresponding to the dialect type into the current session memory context, and initialize the dialect-compatible session context according to the global unified configuration flag.

[0013] The dialect-compatible session context includes the dialect type and transaction protection switch. Figure 2 This diagram illustrates the system architecture of a database dialect transaction semantic compatibility system provided in this embodiment. This system, mounted as a Dynamic Link Library (.so file) extension on the PostgreSQL kernel, consists of an AST dynamic routing and degradation module, a metadata and identifier virtualization module, a data type inference and semantic rewriting module, and a compatibility concurrency and fine-grained transaction semantics module. These modules are not isolated rule stacks but rather collaborate serially according to the statement lifecycle under the same dialect-compatible session context (DialectCompatContext). This context is established by S100 during the connection handshake phase and includes at least the following fields: dialect type, session GUC flag, statement number, original SQL summary, AST transformation status, identifier mapping result, type inference result, transaction protection switch, degradation status, and degradation reason. This context serves as the unified data carrier for subsequent modules to read and update. Figure 2 As shown, the heterogeneous SQL data stream sent by the client first passes through the TCP / IP connection pool. During the handshake phase, S100 injects a dialect flag and generates a dialect-compatible session context. Subsequently, S200 selects a dialect parsing dynamic library based on this context, standardizing the heterogeneous SQL text into a RawStmt syntax tree recognizable by the PostgreSQL kernel. S300 performs metadata and identifier virtualization based on this RawStmt. S400 combines the identifier mapping results and the type compatibility matrix to complete type inference and semantic rewriting. S500 reads the same context at the executor entry point, determines whether to inject a micro-savepoint based on the dialect state, and performs statement-level isolation for execution-time exceptions. When no heterogeneous dialect is recognized, the system directly enters the PG native path. When a controlled degradation occurs, the system writes the degradation state into the context and then determines whether to enter the conservative processing branch of S300-S500 based on the PG native parsing results.

[0014] The following is combined Figure 1 and Figure 2The embodiments of this specification are described below. In one embodiment, in step S101, during the start-up message phase of establishing a TCP connection between the client and the target database, the system intercepts connection attributes and extracts the dialect type of the source database. A globally unified configuration (GUC) flag representing the dialect type (e.g., compatible_dialect = 'oracle' or 'tsql') is written to the current session memory context. Subsequently, the system generates a dialect-compatible session context based on this GUC flag and makes it available for subsequent modules to read through a unified access interface. This is used to identify the source database dialect type without modifying the client's business SQL and to initialize the current connection. Figure 2 The S200-S500 systems share a session-level context. Specifically, S200 reads this context at the parsing entry adapter interface to select the dialect parser library and AST adapter; S300 reads the context before object name parsing to select identifier folding, truncation defense, and data dictionary virtualization strategies; S400 reads the context before type checking and expression rewriting to select the type conversion matrix; and S500 reads the context before executor startup to determine whether to inject micro-savepoints. Dialect types and rule matrices are cached at the session level, while AST conversion states, identifier mapping results, and type inference results are cached at the statement level. When the session GUC is reset or the connection is closed, the above caches are synchronously invalidated.

[0015] Step S102: Receive the original SQL string sent by the client, and perform multi-dimensional processing on the original SQL string according to the dialect type in the dialect compatibility session context to generate a dialect-adapted standardized execution plan.

[0016] Figure 1 In step S102, the original SQL string is processed in multiple dimensions according to the dialect type in the dialect-compatible session context to generate a dialect-adapted standardized execution plan. Specifically, this includes: converting the original SQL string into a syntax tree structure recognizable by the target database according to the dialect type in the dialect-compatible session context; dynamically folding the identifiers in the syntax tree structure into case and rewriting the expressions in the syntax tree structure into type-compatible expressions to determine the current syntax tree structure; and using the current syntax tree structure to determine the dialect-adapted standardized execution plan.

[0017] By sequentially processing syntax tree transformation, identifier case folding, and expression type rewriting, the dialectal structured query language of heterogeneous databases is gradually transformed into a standardized execution plan recognizable by the target database. Compared to conventional string replacement or hard-coded parser modification methods, this approach achieves syntax-level compatibility in a modular and pluggable manner, providing a unified and executable input for subsequent transaction semantic protection and avoiding execution plan generation failures due to syntax differences or type mismatches.

[0018] Specifically, based on the dialect type in the dialect-compatible session context, the original SQL string is converted into a syntax tree structure recognizable by the target database. This includes: selecting a dialect parsing dynamic library corresponding to the dialect type from a preset dialect parsing dynamic library; calling the dialect parsing dynamic library to parse the original SQL string into a heterogeneous abstract syntax tree; inputting the heterogeneous abstract syntax tree into a visitor pattern adapter, recursively traversing the nodes of the heterogeneous abstract syntax tree through the visitor pattern adapter, reassembling and mapping each traversed node into a raw statement node recognizable by the target database, generating a sequence of raw statement nodes, and then converting the raw statement node into a single statement. The statement node sequence serves as the syntax tree structure. When an unrecognized private syntax node is encountered during recursive traversal, a controlled silent degradation is triggered, destroying the temporary syntax tree and statement-level cache of the current statement. The degradation status, incompatible node type, and degradation error code are recorded in the dialect-compatible session context, and the original SQL string is returned to the native parser of the target database. In response to the native parser successfully generating the original statement node, the abstract syntax tree transformation status in the dialect-compatible session context is marked as the native degradation state. In response to the native parser failing to generate the original statement node, the context of the current statement is cleaned up, and a syntax error formatted according to the dialect type is returned to the client.

[0019] A controlled silent degradation mechanism is introduced during the syntax tree transformation process. When the heterogeneous syntax tree transformation encounters an unrecognized private syntax node, instead of directly throwing a fatal error and interrupting the entire processing flow, controlled degradation is triggered. After destroying temporary data, the original structured query language is reverted to the target database's native parser for processing. Based on the processing result of the native parser, the system can choose to continue executing subsequent standardized plan generation steps or return a formatted syntax error. This significantly improves the system's fault tolerance and stability, avoiding the interruption of the entire batch of parsing tasks due to a single point of syntax incompatibility.

[0020] In one embodiment of this specification, after the dialect type has been identified and the context has been established, Dynamic Routing & Controlled Fallback based on the dialect context (AST) is performed to convert heterogeneous SQL text into a RawStmt syntax tree that can be recognized by the PostgreSQL kernel.

[0021] Specifically, at the syntax processing entry point of the target database, the system sets up a parsing entry adaptation interface as the first routing hub. This parsing entry adaptation interface can be implemented by a combination of publicly available post-parsing analysis hooks in PostgreSQL, query processing entry callbacks, dynamically loaded dialect parsing library entry functions, or equivalent extension points in the plugin adaptation layer that match a specific PostgreSQL version. It is not limited to a native hook with a fixed name. When the parsing entry adaptation interface receives the raw SQL string, it first reads the dialect-compatible session context cached in step S101 and dynamically decides whether to dispatch the SQL load to the corresponding dialect parsing dynamic library (such as oracle_parser.so), or, if the dialect rule is not matched, to yield to the native PG parsing process.

[0022] To prevent multi-statement scripts containing multiple logical instructions from crashing the entire batch processing queue due to a single point of syntax error during parsing, the `MODE_SINGLE_QUERY` flag is enforced at this level, splitting the complex text into atomic, independent sequences of abstract syntax trees. The initial syntax tree generated by the heterogeneous parsing library is fed into an adapter based on the Visitor Pattern. This adapter recursively traverses the heterogeneous syntax tree nodes, reassembling and mapping them to PG's native standard `RawStmt` (raw statement) nodes.

[0023] If an incompatible private syntax node is encountered during recursion, a controlled silent fallback is triggered. First, the temporary syntax tree and statement-level cache for the current statement are destroyed. The SQL hash, dialect type, incompatible node type, fallback error code, and fallback time are recorded in the dialect-compatible session context. By default, the complete SQL text is not recorded to avoid sensitive information leakage. Then, the original SQL string is returned to the PG native parser for fallback parsing. If the PG native parser can generate a RawStmt, the context state is marked as FALLBACK_NATIVE_RAWSTMT. Figure 2 S300 and S400 in the system enter a conservative mode where only the rules that have met the safety preconditions are executed. Figure 2The S500 in the executor still reads the context at the executor entry point and determines whether statement-level micro-savepoint protection is enabled. If the PG native parser still fails, the statement will not enter the executor; the parsing entry error protection logic is responsible for cleaning up the current statement context, mapping and returning the syntax errors in the corresponding dialect format to prevent error states from polluting subsequent statements.

[0024] For transaction semantics after controlled degradation, a cooperative rather than mutually exclusive strategy is adopted, as long as the original SQL can enter the executor after being parsed by PG natively. Figure 2 The S500 in the middle can still inject micro-savepoints based on dialect-compatible session context to ensure that execution-time errors are limited to the current statement; only when an error occurs in the parsing stage and no executable RawStmt is generated will the executor-level micro-savepoint not be triggered, and the parsing entry error protection logic will complete the context cleanup and error return.

[0025] Figure 1 In the specific implementation of step S102, dynamic case folding is performed on the identifiers in the syntax tree structure, and type compatibility rewriting is performed on the expressions in the syntax tree structure to determine the current syntax tree structure. Specifically, this includes: in the object name resolution stage of the target database, according to the dialect type in the dialect compatibility session context, the relation name resolution adaptation interface is called to perform dynamic case folding rules on the relation names in the syntax tree structure to obtain a first syntax tree structure containing standardized relation name identifiers; in the type checking and expression rewriting stage of the target database, according to the dialect type in the dialect compatibility session context, the type conversion path adaptation interface is called to query the preloaded dialect type compatibility conversion matrix; when it is detected that the native execution planner blocks plan generation due to data type mismatch, according to the mapping path hit in the dialect type compatibility conversion matrix, conversion nodes are dynamically added to the first syntax tree structure to generate the current syntax tree structure containing type conversion logic.

[0026] This system dynamically folds identifiers in the syntax tree structure for case folding and rewrites expressions for type compatibility. It determines the current syntax tree structure and defines the specific operations for identifier case folding and type rewriting. By calling the relation name resolution adaptation interface, it dynamically adjusts the identifier case folding rules according to the dialect type, resolving system-level conflicts related to case sensitivity between heterogeneous databases. Furthermore, by querying the dialect type compatibility conversion matrix and dynamically inserting conversion nodes into the expression tree, it enables the target database's native execution planner to generate an executable plan containing implicit type conversion logic. This achieves transparent adaptation of identifier naming rules and automatic type compatibility for cross-database expressions without modifying the target database kernel.

[0027] Figure 1In the specific implementation of step S102, after dynamically folding the identifiers in the syntax tree structure, the method further includes: calling the long identifier fidelity adaptation interface to detect whether the length of the relation name and / or identifier in the syntax tree structure exceeds the maximum length limited by the target database kernel; when the maximum length is detected, calling the hash algorithm to perform a hash operation on the relation name and / or identifier to generate a hash value; truncating the relation name and / or identifier to within the maximum length to form a truncation prefix, and appending the hash value to the truncation prefix to form a short identifier, wherein the short identifier is used for physical storage; constructing a bidirectional mapping table in shared memory, establishing a binding relationship between the identifier and the short identifier in the bidirectional mapping table, and managing the storage space of the bidirectional mapping table using a least recently used strategy.

[0028] In one embodiment of this specification, the output PG-recognizable syntax tree (i.e., the syntax tree structure recognizable by the target database) and the dialect-compatible session context are used as input. Based on the standardized RawStmt metadata truncation defense and system dictionary virtualization (Metadata Virtualization & Identifier Defense), the problem of foreign key, index and other reference relationships being invalidated due to the violent truncation of excessively long object names in heterogeneous dialects is solved, and the data dictionary is transparently presented to the front end.

[0029] Specifically, when a third-party migration tool attempts to read database metadata, a virtual schema (such as sys, dbo, or dba) is implicitly mounted at the forefront of the current session's schema search path. This schema pre-deploys a large number of highly encapsulated virtual views, which are underlyingly mapped to PG's native system directories (such as pg_catalog.pg_class, pg_attribute, etc.). Thus, the system can accurately simulate the dictionary table structure of the source heterogeneous database (such as Oracle's DBA_TABLES) for external reading.

[0030] During the object name resolution phase, a relation name resolution adapter interface is set up. This interface can be implemented using a combination of PostgreSQL's publicly exposed post-parse analysis hooks, system directory access callbacks, object access hooks, or plugin-internal object resolution encapsulation layers, and is not limited to a fixed hook name that exists in a specific version. When the PG kernel or plugin adapter layer looks up the corresponding OID (Object Identifier) ​​based on the relation name, the relation name resolution adapter interface performs dynamic case folding rules according to the current dialect context, resulting in a first syntax tree structure containing the standardized relation name identifier. For example, when compatible with Oracle, an implicit conversion to uppercase is automatically performed to resolve system-level conflicts between PG's default lowercase conversion and the source dialect's case rules.

[0031] Furthermore, a non-cryptographic hash algorithm is introduced to resist long identifier truncation. Since PG's native macro definition NAMEDATALEN strictly limits the maximum identifier length to 64 bytes (63 bytes of effective characters), which is the maximum length limited by the target database kernel, this directly clashes with systems like SQL Server that support longer identifiers. A long identifier fidelity adaptation interface is set up before identifier normalization and object creation. This interface can be implemented through the post-parsing analysis stage, DDL processing stage, object creation verification stage, or a plugin-defined identifier encapsulation layer, rather than being limited to a fixed-name truncation hook. When an over-limit identifier is detected, the MurmurHash3 (32-bit variant) hash algorithm is called to operate on the complete string, appending the hash result to the truncation prefix to generate a unique and fixed-length secure short name (i.e., a short identifier) ​​for disk persistence. Simultaneously, a bidirectional mapping table is maintained to strictly bind the source long identifier to the short identifier. When the data dictionary outputs results, this table is queried in reverse to restore the long identifier output, achieving separation between physical layer truncation and logical layer fidelity.

[0032] Long identifier fidelity adaptation interface and relation name resolution adaptation interface are used to manage ultra-long object identifiers with a bidirectional mapping mechanism. The above adaptation interfaces can be implemented by a combination of PostgreSQL public extension entry, DDL processing entry, object access entry, system directory access encapsulation layer, or plugin internal object resolution encapsulation layer, and are not limited to a native hook with a fixed name in a specific version. The long identifier fidelity adaptation interface intercepts over-limit identifiers and calls a non-cryptographic hash algorithm, preferably the 32-bit variant of MurmurHash3. Equivalent algorithms include but are not limited to CityHash, SpookyHash, SipHash, and Jenkins Lookup3, to generate collision-resistant short names and physically persist them to disk. A bidirectional mapping table is maintained in shared memory with an LRU strategy to bidirectionally bind complete long identifiers and short identifiers. The relation name resolution adaptation interface performs a reverse lookup on the metadata output path to transparently restore the long identifier, realizing the separation of physical layer truncation and logical layer fidelity.

[0033] By detecting whether the identifier length exceeds the maximum length limit of the target database kernel, a hash algorithm is called to generate a hash value for the over-limit identifier, and this hash value is appended to the truncation prefix to form a short identifier for physical storage. At the same time, a binding relationship between the complete identifier and the short identifier is established in a bidirectional mapping table in shared memory. This achieves the separation of physical layer truncation and logical layer fidelity. When metadata is output externally, the long identifier can be recovered by reverse table lookup, which solves the problem of invalidation of foreign key, index and other reference relationships caused by identifier length limit conflicts between heterogeneous databases.

[0034] After the identifier resolution and mapping are completed in the above steps, the data type inference intervention and semantic rewriting (Coercion Pathway & Collation Semantics) steps based on the metadata mapping results are executed. The statement-level type inference state is read through the dialect-compatible session context to intervene in the PostgreSQL strong-type system and introduce the weak-type implicit conversion feature that is widely present in heterogeneous databases.

[0035] Specifically, a type conversion path adaptation interface is set up during the type checking and expression rewriting phases. This interface can be implemented by a combination of PostgreSQL's publicly exposed post-parsing hooks, planning phase hooks, expression tree rewriting entry points, or plugin internal type inference encapsulation layers, and is not limited to a native type conversion hook with a fixed name. When the native execution planner may block parsing or plan generation due to type mismatch (such as attempting to calculate the addition of the string '100' and the integer 10), this interface queries the pre-loaded dialect type compatibility conversion matrix in memory. If a rule is matched, an equivalent CoerceExpr, CoerceViaIO, or other valid conversion node is dynamically added to the expression tree, i.e., the corresponding first syntax tree structure containing standardized relation name identifiers, allowing the planner to continue generating executable logic.

[0036] Figure 1 After generating the dialect-adapted standardized execution plan in step S102, the method further includes: in the collation selection and expression comparison semantic binding stage of the target database, calling the collation adaptation interface; through the collation adaptation interface, loading the corresponding character set collation rule from memory according to the dialect type in the dialect-compatible session context, and binding the collation rule to the scan node or comparison expression node in the standardized execution plan, so that the target database simulates the case-insensitive comparison or trailing space ignoring semantics of the source database when performing character data comparison.

[0037] The above technical solution limits the additional steps of sorting rule adaptation. After the standardized execution plan is generated, the sorting rule adaptation interface is called and the corresponding character set sorting rule is loaded according to the dialect type. The rule is then bound to the scan node or comparison expression node of the execution plan, so that the target database can simulate the case-insensitive comparison or trailing space ignoring semantics of the source database when performing character data comparison. This achieves consistency in sorting and comparison semantics between heterogeneous databases and further improves the fidelity of dialect compatibility.

[0038] Specifically, a collation adaptation interface is set up during the collation selection and expression comparison semantic binding phases. This interface can be implemented by the collation encapsulation layer provided by the post-parsing analysis phase, planning phase, expression rewriting phase, or plugins, and is not limited to a fixed collation hook name that exists in a specific version. Before generating the execution plan scan node or comparison expression node, the system binds a dialect-specific character set collation (Collation) to the dialect-compatible session context, ensuring that core comparison semantics such as case-insensitive comparison and trailing space ignoring remain consistent with the source heterogeneous database.

[0039] Step S103: Obtain the transaction protection switch in the dialect-compatible session context. When the transaction protection switch indicates that the current session is in dialect-compatible mode, before the target statement in the standardized execution plan is executed, call the transaction manager interface of the target database to create an internal sub-transaction as the corresponding current micro-savepoint.

[0040] This approach addresses global transaction crashes by employing dialect-context-aware micro-savepoint injection and fine-grained transaction semantics. In this specification, a micro-savepoint, as used in the embodiments, refers to a statement-level protection point implemented using the PostgreSQL internal sub-transaction C API, automatically created and released by the server-side plugin, and invisible to the client. The micro-savepoint terminology is used consistently throughout the embodiments, with the internal sub-transaction serving only as the kernel implementation mechanism for this micro-savepoint. Statement-level rollback is achieved through executor hooks bound to dialect-compatible session contexts, and lifecycle control—creating and deleting as needed—prevents the continuous accumulation of savepoints within long transactions, structurally reducing the risk of PostgreSQL suboverflow disk overflow. The difference between micro savepoints and standard SQL savepoints lies in their nature. Micro savepoints are anonymous statement-level protection points automatically injected by the plugin within the server via the C API, eliminating the need for the client to send SAVEPOINT / ROLLBACK TO SAVEPOINT / RELEASESAVEPOINT commands. Standard SQL savepoints, on the other hand, are SQL objects explicitly named and managed by the client, typically requiring additional network round trips and SQL parsing. The lifecycle of a micro savepoint is confined to a single statement; it is released immediately upon successful execution and rolled back and released immediately upon failure. Therefore, it does not continuously accumulate sub-transaction records like explicit savepoints repeatedly retained within long transactions.

[0041] exist Figure 1In step S103, the transaction manager interface of the target database is called to create an internal sub-transaction as the corresponding current micro-savepoint. Specifically, this includes: identifying the type of the current lifecycle node at the lifecycle node of the target database executor, where the type includes executor startup hooks for data manipulation language instructions and tool statement processing hooks for data definition language and cursor instructions; when the type of the current lifecycle node is the tool statement processing hook, the current instruction type is identified. If the current instruction type is a data definition language that does not support rollback, the step of creating an internal sub-transaction is skipped, and the native instruction path is executed directly; when it is determined that a micro-savepoint needs to be created, the transaction manager interface of the target database is called to create an internal sub-transaction, and the internal sub-transaction is bound to the target statement to be executed as the current micro-savepoint; during the execution of the target statement, the sub-transaction identifier of the current micro-savepoint is recorded in shared memory; after the target statement is executed successfully or fails, the sub-transaction identifier is removed from the shared memory by calling the sub-transaction release interface or the sub-transaction rollback and release interface, so that the number of active sub-transactions in the shared memory does not exceed the preset statement-level concurrency threshold at any time.

[0042] The aforementioned technical solution defines the type identification of executor lifecycle nodes and the data definition language (DDL) skipping mechanism during micro-savepoint creation. By distinguishing between executor startup hooks for DDL instructions and tool statement processing hooks for DDL and cursor instructions, it skips micro-savepoint creation on DDL instructions that do not support rollback and directly executes the native instruction path, thus avoiding the forced application of sub-transaction protection to operations that do not support rollback. At the same time, by recording sub-transaction identifiers in shared memory and removing them immediately after statement execution, the number of active sub-transactions in shared memory is always kept at a low level, structurally avoiding disk overflow performance penalties caused by sub-transaction overflow and solving the performance degradation problem in long-transaction, high-frequency DDL scenarios.

[0043] In one embodiment of this specification, in conjunction with Figure 2 The S500 was analyzed, and at key lifecycle nodes of the system executor, ProcessUtility_hook (for DDL structure definitions and cursor-specific instructions) and ExecutorStart_hook (for DML data manipulation instructions) were respectively mounted as interceptors. After the interceptors are triggered, they first read data through the unified access interface. Figure 1 Step S101 (i.e., corresponding to) Figure 2The system establishes a dialect-compatible session context (S100). If the context indicates that the current session is a native PG session, or has been marked as parsing failed and has not entered the executor, control is immediately relinquished. If the context indicates that the current statement belongs to a dialect session that requires transaction semantic compatibility protection, BeginInternalSubTransaction(NULL) is called to create a micro-savepoint internally on the server side. The creation of a micro-savepoint differs from the standard SQL SAVEPOINT. SQL SAVEPOINT requires the client to explicitly send a named SQL command and undergo network transmission and SQL parsing, while micro-savepoints are automatically completed by the plugin at the executor entry point via the C API. This does not increase client network round trips, does not expose the business SQL, and does not introduce application-layer compensation logs. Whether business data changes generate a WAL is still determined by the original SQL itself.

[0044] Step S104: Execute the encapsulated standard executor function through the exception capture block. In response to the successful or failed execution status of the standard executor function, merge or roll back the current micro-savepoint to achieve statement-level atomic lifecycle management.

[0045] exist Figure 1 In step S104, in response to the successful or failed execution of the standard executor function, the current micro-savepoint is merged or rolled back. Specifically, in response to the successful execution of the standard executor function, the sub-transaction release interface is called to merge the result of the current micro-savepoint into the parent transaction; in response to the failure of the standard executor function and the throwing of an error signal, the sub-transaction rollback and release interface is called in the exception capture block to undo all changes to the current micro-savepoint, and the error status clearing interface is called to mark the top-level transaction status as active, and the kernel error code is mapped to the source database format error information according to the dialect type.

[0046] When a statement executes successfully, the micro-savepoint result is immediately merged into the parent transaction, making the changes made by that statement a persistent part of the top-level transaction. When a statement fails, all changes to the micro-savepoint are rolled back and released in the exception handling block. Error flags are cleared to restore the top-level transaction to an active state, and kernel error codes are mapped to error messages in the source database format according to the dialect type. Compared to the conventional approach where errors cause global transaction aborts, this approach achieves semantic compatibility with partial failures without global crashes, and the error message format conversion ensures transparent adaptation for client applications.

[0047] The following is combined Figure 2 S500 in Figure 1In step S104, the system uses the C language-level macro definition PG_TRY() to wrap and protect the standard executor running function (such as standard_ExecutorRun) with a code block.

[0048] If the underlying executor successfully completes data processing and reaches PG_END_TRY(), i.e., in response to the standard executor function's successful execution status, the system immediately calls ReleaseCurrentSubTransaction() to release the current micro-savepoint. This operation merges the memory state, lock state, and data changes of the current statement into the parent transaction and removes the active sub-transaction record corresponding to that statement; subsequent statements continue to execute within the same top-level transaction, and the final COMMIT only commits the results of all successfully merged statements. Through single-statement creation and single-statement release lifecycle control, the system avoids retaining a large number of sub-transaction records within long transactions, thereby reducing the risk of triggering a suboverflow disk overflow after exceeding 64 sub-transactions. Based on benchmark test data (environment: PostgreSQL 15.4, 100 concurrent connections, 50 DML statements per transaction on average, lasting 300 seconds), the solution in this specification's embodiments reduces throughput loss from approximately 40%–60% to less than 3% compared to the client-side SAVEPOINT solution, with zero additional network round trips. Compared to server-side solutions without Suboverflow protection, it avoids latency peaks caused by disk overflow in long-transaction, high-frequency DML scenarios.

[0049] In response to a standard executor function failure and the throwing of an error signal, that is, if a statement-level error such as a unique constraint violation or data truncation is triggered during execution, the ERROR signal thrown by the underlying storage engine is blocked by the outer PG_CATCH() exception capture block to prevent it from propagating further to the top-level global transaction manager. Inside the capture block, the system immediately calls RollbackAndReleaseCurrentSubTransaction() to roll back and release the current micro-savepoint, restoring the database cache, system table row state, and data changes generated by the failed statement to their state before the micro-savepoint was injected; therefore, when subsequent statements execute successfully and eventually COMMIT, the changes from the previously failed statement will not take effect. Subsequently, the system calls FlushErrorState() to clear the current error flag, keeping the top-level transaction state ACTIVE, and mapping the kernel error code to the corresponding heterogeneous database format (such as Oracle's ORA-00001) for subsequent exception handling logic. If subsequent statements fail again, the system repeats the single-statement isolation process of "creating micro-savepoints, catching exceptions, partial rollback, and cleaning up error states"; if a connection interruption, PANIC, or unrecoverable kernel error occurs, it is still handled by the PostgreSQL top-level transaction mechanism.

[0050] In one embodiment of this specification, when a client application initiates a DML or supported DDL instruction, the intercept hook first reads the dialect-compatible session context for gating checks. Upon successful gating, it calls the transaction manager's native CAPI BeginInternalSubTransaction to allocate micro-savepoints and enters the execution phase protected by PG_TRY(). If the core execution engine reports successful execution (branch A), the intercept hook calls ReleaseCurrentSubTransaction to merge the current statement result into the parent transaction. If the core execution engine encounters a data conflict and triggers an exception (branch B), the exception is intercepted by PG_CATCH. The intercept hook then calls RollbackAndReleaseCurrentSubTransaction to strip the local state of the failed statement and executes FlushErrorState to clear the error flags. Thus, the application layer can receive error codes mapped according to the source dialect format, while the top-level transaction remains active and can continue processing subsequent statements.

[0051] To address the performance issue of suboverflow disk overflow caused by PostgreSQL's inherent 64-subtransaction shared memory limit, this specification's implementation calls `BeginInternalSubTransaction` to allocate subtransaction boundaries before executing each statement intercepted by the hook; and immediately calls `ReleaseCurrentSubTransaction()` to dissolve the subtransaction after successful statement execution, instead of waiting until the end of the transaction to release it in batches. This ensures that the number of active subtransactions in shared memory never exceeds single digits at any given time, fundamentally avoiding the suboverflow triggering conditions. Compared to existing technologies using client-side `SAVEPOINT` and those without server-side suboverflow protection, this approach has clear technical advantages and can be deployed independently in either dialect-aware or non-dialect-aware modes, possessing independent protection value.

[0052] In conclusion, Figure 2 The data flow for inter-module collaboration is as follows: S100 outputs a dialect-compatible session context, which serves as the sole cross-module state entry point; S200 consumes the dialect types within it and writes them into the AST transformation state; S300 consumes the AST transformation state and writes the identifier mapping results; S400 consumes the identifier mapping results and writes the type inference and semantic rewriting results; S500 consumes the aforementioned states and decides at the executor entry point whether to inject micro-savepoints. Each module only passes structured state through this context, without directly sharing temporary syntax tree pointers or private rule tables, thus ensuring clear and auditable collaboration relationships within the plugin layer.

[0053] The above-described at least one technical solution used in the embodiments of this specification can achieve the following beneficial effects: By establishing a dialect-compatible session context that includes dialect type and transaction protection switches during the connection handshake phase, subsequent processing can be aware of the dialect pattern of the current session, avoiding unnecessary overhead to the native session. Based on this, the original structured query language is processed in multiple dimensions according to the dialect type to generate a standardized execution plan. At the executor lifecycle nodes, internal sub-transactions are conditionally created as micro-savepoints based on the transaction protection switches, and statement-level atomic lifecycle management is achieved through exception handling blocks. This method is implemented as a server-side plugin, requiring no modification to the target database kernel source code, adding no network round trips to the client, and binding transaction protection with dialect awareness, achieving high-fidelity compatibility with heterogeneous database transaction semantics.

[0054] To fully demonstrate the feasibility of the embodiments in this specification under various highly complex business scenarios, the following are specific implementation examples provided in the embodiments of this specification: Example 1 illustrates heterogeneous migration and fault-tolerant handling compatible with Oracle financial accounting systems.

[0055] Example 1's technical background: A large commercial bank's core accounting system has long been running on an Oracle database architecture. Due to business evolution, it is now necessary to migrate its entire codebase to a PostgreSQL cluster environment. The system contains tens of thousands of complex stored procedures, which extensively utilize PL / SQL exception tolerance frameworks similar to the following: BEGIN INSERT INTO account_log (trans_id, status) VALUES (v_id, 'PROCESSING'); EXCEPTION WHEN DUP_VAL_ON_INDEX THEN UPDATE account_log SET status = 'RETRY' WHERE trans_id = v_id; END; If migrated directly to a standard PostgreSQL system that has not been modified according to the embodiments in this specification, when an INSERT statement triggers a unique index conflict (DUP_VAL_ON_INDEX) error, the PG kernel will immediately determine that the entire stored procedure transaction is in an Abort state. Subsequent UPDATE compensation operations will be directly rejected, causing a serious break in the financial accounting logic.

[0056] When using the system provided in the embodiments of this specification, the client driver passes the GUC parameter flag compatible_dialect = 'oracle' to the database server during the initial handshake phase of the connection (step S101). Subsequently, the stored procedure load containing the above code block is correctly routed and reconstructed via the parsing entry adaptation interface. When the planner is ready to execute the internal INSERT statement, the ExecutorStart_hook mounted on the server is precisely triggered. The hook function first checks the GUC dialect flag to confirm that the current session is in Oracle dialect compatible mode, and then calls the kernel C API BeginInternalSubTransaction(NULL) to allocate micro-savepoint space. When attempting to execute data writing, a conflict is caused by an error in the underlying index mechanism. The error signal is propagated upwards and safely captured by the wrapped PG_CATCH macro. The code logic within the capture block immediately executes RollbackAndReleaseCurrentSubTransaction() to strip the dirty write cache caused by the failed INSERT statement and calls FlushErrorState() to clean up the transaction abort flag. Ultimately, the error code 23505 thrown by the PG underlying layer was translated and matched to the Oracle-compatible DUP_VAL_ON_INDEX. The original control flow was able to enter the EXCEPTION branch normally, and the subsequent UPDATE statement was successfully executed. This entire process was completed autonomously by the server system without adding any extra network interaction burden. Furthermore, because micro-savepoints are created and deleted as needed, the number of sub-transactions in shared memory is always kept within a controllable range, and suboverflow is not triggered.

[0057] Example 2 is a version compatible with Greenplum distributed data warehouse and PostgreSQL derivative.

[0058] The technical background of Example 2 is as follows: In large-scale parallel processing (MPP) distributed data warehouse platforms represented by Greenplum, and cloud-native distributed PG derivatives represented by PolarDB for PostgreSQL and TDSQL-PG, the need for heterogeneous database dialect compatibility is also widespread. These platforms have the following unique characteristics at the distributed transaction processing level: First, the definitions of some internal C API header files in the distributed execution plan may differ depending on the version branch; the BeginInternalSubTransaction function signature has been refactored in some Greenplum kernel branches. Second, the cross-node transaction consistency mechanism between the distributed coordinator and compute nodes (Segments) differs fundamentally from that of single-node PGs. Third, the access path of pg_subtrans to read-only nodes in shared storage architectures such as PolarDB differs in detail from that of standard PGs.

[0059] To address the aforementioned differences, the embodiments in this specification provide the following adapted implementation methods, all of which fall within the scope of equivalent techniques for the core methods in the embodiments of this specification: (1) Internal C API Abstraction Layer Adaptation. During the system initialization phase, the extension module uses dynamic symbol resolution (dlsym) to detect whether the target platform has the standard BeginInternalSubTransaction function exported symbol. If it exists, it is called directly; if the symbol is unavailable due to version branch, the system switches to the alternative implementation path: by directly manipulating the linked list pointer of the underlying transaction context core structure TransactionStateData, or by using the system's internal virtual transaction identifier (Virtual Transaction ID, vxid) to establish an equivalent error defense mechanism, the same local state isolation effect is achieved.

[0060] (2) Distributed Coordinator Adaptation. On the Greenplum Coordinator node, the modules in the embodiments of this specification work normally in the Coordinator's connection processing layer; for the execution plan sent to the Segment node, the embodiments of this specification capture and translate the distributed transaction exception error codes returned by the Segment node through the micro-savepoint mechanism of the Coordinator layer, maintain the availability of the top-level distributed transaction, and achieve logical statement-level rollback compatibility.

[0061] (3) Read-only node protection. In shared storage architectures such as PolarDB, the system automatically determines whether to enable micro-savepoint injection logic by detecting the current node role (read-write master node or read-only node), ensuring that read-only nodes are not triggered by pg_subtrans write operations related to savepoints, thus ensuring the overall stability of the cluster.

[0062] The above adaptation strategy fully demonstrates the cross-platform portability and engineering robustness of the technical solutions in the embodiments of this specification.

[0063] The technical solution provided in the embodiments of this specification injects the heterogeneous database dialect type identifier (GUC flag) into the current session memory context during the connection handshake phase, and uses it as the unique context credential to drive the behavior of all subsequent modules; at key nodes in the lifecycle of the target database executor (ExecutorStart_hook and ProcessUtility_hook), the GUC flag is used as a gating condition to conditionally trigger the allocation of internal sub-transactions at the server-side C API level (BeginInternalSubTransaction), realizing implicit micro-savepoint injection with zero network round trips; when the subquery statement is executed successfully, ReleaseCurrentSubTransaction() is called immediately to resolve the micro-savepoint, keeping the number of sub-transactions residing in shared memory within a safe threshold, thus achieving immunity to the 64-sub-transaction Suboverflow disk overflow defect at the structural level; statement-level errors are captured through the PG_CATCH block and RollbackAndReleaseCurrentSubTransaction() is called to achieve precise rollback of local states, while maintaining the continuous availability of top-level transactions; the above transaction semantic mechanism works in conjunction with AST dynamic routing, metadata virtualization, and type inference to form a complete dialect-based semantically compatible system.

[0064] This specification also provides an embodiment of a database dialect transaction semantics compatible device, such as... Figure 3 As shown, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the above-described method.

[0065] This specification also provides a non-volatile computer storage medium storing computer-executable instructions configured to perform the above-described method.

[0066] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0067] The above are merely one or more embodiments of this specification and are not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A database dialect transaction semantic compatibility method, characterized in that, The method includes: The handshake message during the connection establishment process between the client and the target database is obtained, the dialect type of the source database corresponding to the client is extracted, the global unified configuration flag corresponding to the dialect type is written into the current session memory context, and the dialect compatible session context is initialized according to the global unified configuration flag. The dialect compatible session context includes the dialect type and the transaction protection switch. The system receives the raw SQL string sent by the client, performs multi-dimensional processing on the raw SQL string according to the dialect type in the dialect compatibility session context, and generates a dialect-adapted standardized execution plan. Obtain the transaction protection switch in the dialect-compatible session context. When the transaction protection switch indicates that the current session is in dialect-compatible mode, before the target statement in the standardized execution plan is executed, call the transaction manager interface of the target database to create an internal sub-transaction as the corresponding current micro-savepoint. By executing the encapsulated standard executor function through the exception handling block, and responding to the success or failure status of the standard executor function, the current micro-savepoint is merged or rolled back to achieve statement-level atomic lifecycle management; In response to the successful or failed execution status of the standard executor function, the current micro-savepoint is merged or rolled back, specifically including: In response to the successful execution status of the standard executor function, the sub-transaction release interface is called to merge the result of the current micro-savepoint into the parent transaction; In response to the failure of the standard executor function and the throwing of an error signal, the sub-transaction rollback and release interface is called in the exception capture block to undo all changes to the current micro-savepoint, and the error state clearing interface is called to mark the top-level transaction state as active. The kernel error code is mapped to the source database format error information according to the dialect type. Calling the transaction manager interface of the target database to create an internal sub-transaction as the corresponding current micro-savepoint, specifically including: At the lifecycle node of the target database executor, the type of the current lifecycle node is identified, wherein the type includes executor startup hooks for data manipulation language instructions and tool statement processing hooks for data definition language and cursor instructions; When the type of the current lifecycle node is the tool statement processing hook, identify the current instruction type. If the current instruction type is a data definition language that does not support rollback, skip the step of creating an internal sub-transaction and directly execute the native instruction path. When it is determined that a micro-savepoint needs to be created, the transaction manager interface of the target database is called to create an internal sub-transaction, and the internal sub-transaction is bound to the target statement to be executed, which serves as the current micro-savepoint.

2. The database dialect transaction semantic compatibility method according to claim 1, characterized in that, Based on the dialect type in the dialect-compatible session context, the original SQL string is processed in multiple dimensions to generate a dialect-adapted standardized execution plan, specifically including: Based on the dialect type in the dialect-compatible session context, the original SQL string is converted into a syntax tree structure recognizable by the target database; The identifiers in the syntax tree structure are dynamically folded for case and the expressions in the syntax tree structure are rewritten for type compatibility to determine the current syntax tree structure. The dialect-adapted standardized execution plan is then determined based on the current syntax tree structure.

3. A database dialect transaction semantic compatibility method according to claim 2, characterized in that, Based on the dialect type in the dialect-compatible session context, the original SQL string is converted into a syntax tree structure recognizable by the target database, specifically including: Based on the dialect type in the dialect-compatible conversation context, select the dialect parsing dynamic library corresponding to the dialect type from the preset dialect parsing dynamic library; The dialect parsing dynamic library is invoked to parse the original SQL string into a heterogeneous abstract syntax tree; The heterogeneous abstract syntax tree is input into the visitor pattern adapter. The nodes of the heterogeneous abstract syntax tree are recursively traversed through the visitor pattern adapter. Each traversed node is reassembled and mapped to a raw statement node that can be recognized by the target database, generating a sequence of raw statement nodes. The sequence of raw statement nodes is used as the syntax tree structure. When an unrecognized private syntax node is encountered during the recursive traversal, a controlled silent degradation is triggered, the temporary syntax tree and statement-level cache of the current statement are destroyed, the degradation status, incompatible node type and degradation error code are recorded in the dialect-compatible session context, and the original SQL string is returned to the native parser of the target database. In response to the native parser successfully generating the original statement node, the abstract syntax tree transformation state in the dialect-compatible session context is marked as the native downgraded state. In response to the native parser failing to generate the original statement node, the context of the current statement is cleaned up, and a syntax error formatted according to the dialect type is returned to the client.

4. A database dialect transaction semantic compatibility method according to claim 2, characterized in that, Dynamic case folding is performed on identifiers in the syntax tree structure, and type-compatible rewriting is performed on expressions in the syntax tree structure to determine the current syntax tree structure, specifically including: During the object name resolution phase of the target database, the relation name resolution adaptation interface is called according to the dialect type in the dialect-compatible session context to perform dynamic case folding rules on the relation names in the syntax tree structure, thereby obtaining a first syntax tree structure containing standardized relation name identifiers. During the type checking and expression rewriting phase of the target database, the type conversion path adaptation interface is called to query the preloaded dialect type compatibility conversion matrix based on the dialect type in the dialect compatible session context. When it is detected that the native execution planner blocks plan generation due to data type mismatch, a conversion node is dynamically added to the first syntax tree structure according to the mapping path matched in the dialect type compatibility conversion matrix, thereby generating the current syntax tree structure containing type conversion logic.

5. A database dialect transaction semantic compatibility method according to claim 1, characterized in that, Calling the transaction manager interface of the target database to create an internal sub-transaction as the corresponding current micro-savepoint, specifically including: During the execution of the target statement, the sub-transaction identifier of the current micro-savepoint is recorded in shared memory; After the target statement is executed successfully or fails, the sub-transaction identifier is removed from the shared memory by calling the sub-transaction release interface or the sub-transaction rollback and release interface, so that the number of active sub-transactions in the shared memory does not exceed the preset statement-level concurrency threshold at any time.

6. A database dialect transaction semantic compatibility method according to claim 1, characterized in that, After generating the dialect-adapted standardized execution plan, the method further includes: During the sorting rule selection and expression comparison semantic binding stage of the target database, the sorting rule adaptation interface is invoked; Through the sorting rule adaptation interface, the corresponding character set sorting rule is loaded from memory according to the dialect type in the dialect-compatible session context, and the sorting rule is bound to the scan node or comparison expression node in the standardized execution plan, so that the target database simulates the case-insensitive comparison or trailing space ignoring semantics of the source database when performing character data comparison.

7. A database dialect transaction semantic compatibility method according to claim 2, characterized in that, After performing dynamic case folding on the identifiers in the syntax tree structure, the method further includes: Call the long identifier fidelity adaptation interface to detect whether the length of relation names and / or identifiers in the syntax tree structure exceeds the maximum length limited by the target database kernel. When the maximum length is exceeded, a hash algorithm is invoked to perform a hash operation on the relation name and / or the identifier to generate a hash value. The relation name and / or the identifier are truncated to within the maximum length to form a truncated prefix, and the hash value is appended to the truncated prefix to form a short identifier, wherein the short identifier is used for physical storage; A bidirectional mapping table is constructed in shared memory, and a binding relationship between the identifier and the short identifier is established in the bidirectional mapping table. The storage space of the bidirectional mapping table is managed using a least recently used strategy.

8. A database dialect transaction semantics compatible device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

9. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are configured to perform the method as described in any one of claims 1-7.

Images