Method and device for detecting logic error of built-in SQL function based on function attribute driving

Abstract

The application provides a built-in SQL function logic error detection method and device based on function attribute driving, wherein the method comprises the following steps: obtaining a built-in SQL function set; constructing a triple model for each function in the built-in SQL function set to obtain a built-in SQL function model library, wherein each built-in SQL function model comprises signature, constraint and attribute information; generating a function expression according to the built-in SQL function model library and embedding the function expression into a rich context SQL statement to obtain an original SQL query set; parsing the original SQL query set into an abstract syntax tree and locating a function node by traversing the abstract syntax tree to apply function transformation by function internal conversion or function interconversion to construct a variant SQL query set; comparing the original SQL query set and the variant SQL query set to detect whether there is a built-in SQL function with a logic error; and thus, efficient and accurate detection of the built-in SQL function logic error is realized.

Description

Technical Field

[0001] This invention relates to the field of database management technology, and in particular to a method for detecting logical errors in built-in SQL functions based on function attributes, a device for detecting logical errors in built-in SQL functions based on function attributes, a computer-readable storage medium, and a computer device. Background Technology

[0002] In related technologies, built-in SQL functions are a core foundational component of relational database management systems (DBMS). As predefined operational units, they are widely used across all scenarios of SQL queries, including projection, predicate filtering, grouping and aggregation, and nested expressions, providing standardized operation interfaces for data transformation, calculation, and analysis. Current mainstream database systems typically offer hundreds of built-in SQL functions, covering multiple functional categories such as arithmetic operations, string processing, date and time operations, type conversion, conditional judgment, and aggregation analysis. The correctness of their implementation directly determines the accuracy and reliability of database query results.

[0003] Because the implementation of built-in SQL functions needs to adapt to complex type rules, boundary input processing, implicit type conversion logic, and interaction rules with various modules of the query execution engine, defects are easily introduced during development and long-term maintenance. Among these defects, logical errors are a type that is extremely dangerous and difficult to detect: these errors do not cause database crashes or throw explicit runtime exceptions, but instead return seemingly reasonable but actually incorrect query results. They can spread quietly through downstream computing nodes, ultimately destroying the integrity of data-driven applications. In sensitive scenarios such as financial accounting, government approval, and security verification, they can even cause serious business risks and security problems.

[0004] For the detection of database logical errors, existing technologies mainly fall into two categories: difference testing and metamorphosis testing.

[0005] Among them, the difference testing method identifies anomalies by executing the same query on multiple different database management systems and comparing the consistency of the output results. However, this method is highly dependent on cross-system functional compatibility and loses its effectiveness when the query involves dialect feature functions or system-defined semantics. Furthermore, it cannot detect scenarios where multiple systems have the same implementation error.

[0006] Metamorphosis testing is currently the mainstream detection method. Its core idea is to perform a semantic equivalence transformation on the original query to generate a mutated query. The consistency of the execution results of the two is then verified to determine if errors exist. Typical techniques include NoREC (rewriting an optimizable query into an equivalent form with optimization disabled and comparing the results), TLP (splitting the query into multiple subqueries based on predicate logic and verifying the union of the results is consistent with the original query), and EET (performing an equivalence transformation on the expression to verify consistency). These techniques, by enforcing consistency constraints at the query level, can effectively detect logical errors at the query planner and optimizer levels, such as incorrect query rewriting, abnormal join logic, and predicate evaluation errors. However, they have significant limitations in detecting logical errors in built-in SQL functions.

[0007] On the one hand, existing metamorphic relationships are all designed around relational operators and query structures, without modeling the semantic attributes of built-in functions. This makes it impossible to systematically embed the target function into rich-context query scenarios containing complex operations such as joins, aggregations, and subqueries. Furthermore, many function logic errors are only triggered when interacting with surrounding query operators, and isolated function calls cannot expose these defects. On the other hand, the test oracles of existing methods do not have the ability to perceive function semantics. When the original query and the mutated query execute the same erroneous function calculation, the detection is judged to pass because the output results are "consistent," resulting in oracle pollution and failing to identify the logical errors in the function implementation itself. Summary of the Invention

[0008] This invention aims to at least partially solve one of the technical problems in the aforementioned technologies. To this end, one objective of this invention is to propose a method for detecting logical errors in built-in SQL functions based on function attribute-driven approaches. This method constructs a formal model for built-in SQL functions, including signatures, constraints, and semantic attributes, generates rich-context test queries embedding the target function, and constructs equivalent mutation queries based on the function's semantic attributes. Using cross-query attribute consistency as a test oracle, it achieves efficient and accurate detection of logical errors in built-in SQL functions, effectively covering existing methods that cannot identify function implementation-level defects.

[0009] A second objective of this invention is to provide a computer-readable storage medium.

[0010] The third objective of this invention is to provide a computer device.

[0011] The fourth objective of this invention is to propose a built-in SQL function logic error detection device based on function attribute driving.

[0012] To achieve the above objectives, a first aspect of the present invention proposes a method for detecting logical errors in built-in SQL functions based on function attribute-driven methods. The method includes the following steps: obtaining a set of built-in SQL functions; constructing a triplet model for each function in the set to obtain a library of built-in SQL function models, wherein each built-in SQL function model includes signature, constraints, and attribute information; generating function expressions based on the library of built-in SQL function models and embedding them into rich-context SQL statements to obtain a set of original SQL queries; parsing the original SQL query set into an abstract syntax tree and traversing the abstract syntax tree to locate function nodes, thereby constructing a set of mutated SQL queries through intra-function or inter-function transformations; and comparing the results of the original SQL query set and the mutated SQL query set to detect whether any built-in SQL functions have logical errors.

[0013] In addition, the built-in SQL function logic error detection method based on function attribute driving proposed in the above embodiments of the present invention may also have the following additional technical features:

[0014] Optionally, a built-in SQL function model can be constructed based on the following formula:

[0015]

[0016] Where f represents a built-in SQL function, This represents the callable interface of f, which enumerates all overloaded versions of its functions. Each overload includes the function name, category, number of parameters, data type of each parameter, and return type. This represents the semantic constraints required for the effective execution of the record, which defines parameter semantic constraints for each overloaded version; This represents the function properties used to instantiate transformations, including intra-function properties and inter-function properties.

[0017] Optionally, generating function expressions based on the built-in SQL function model library and embedding them into rich-context SQL statements to obtain the original SQL query set includes: selecting and instantiating a query skeleton with expression slots, and deriving slot constraint contracts from surrounding sentences to determine the expected return type and allowed function types of the slots; sampling target functions from the target function set and assigning them to slots, and obtaining overloaded signatures compatible with the slots from the signature set of the target functions; obtaining a list of parameter constraints for the overloaded signatures from the built-in SQL function model, and calling parameter generation logic for each parameter position to construct a compliant expression to combine all parameter expressions into a parameter vector; constructing a complete expression for the target function based on the parameter vector, and replacing the placeholder slots in the query skeleton with the complete expression to obtain the original SQL query.

[0018] Optionally, the original SQL query set is parsed into an abstract syntax tree, and the abstract syntax tree is traversed to locate function nodes, so as to construct a mutated SQL query set by applying function transformation through intra-function transformation or inter-function transformation. This includes: parsing the original SQL query set into an abstract syntax tree, traversing and locating all target function nodes; matching the corresponding attribute template for each target function node, and selecting an applicable transformation rule to obtain the target function expression, wherein the transformation rule includes intra-function transformation and inter-function transformation, where intra-function transformation directly replaces the expression based on a single function attribute, and inter-function transformation replaces the expression based on cross-function equivalence relations; keeping the other structures of the original SQL query unchanged, only replacing the target function expression to generate attribute-equivalent mutated SQL queries.

[0019] Optionally, a built-in SQL function that compares the results of the original SQL query set and the mutated SQL query set to detect whether there is a logical error includes: if the query results of the original SQL query set and the mutated SQL query set are completely consistent, then it is determined that there is no logical error; if the query results of the original SQL query set and the mutated SQL query set are different, then it is determined that there is a logical error.

[0020] To achieve the above objectives, a second aspect of the present invention provides a computer-readable storage medium storing a built-in SQL function logic error detection program based on function attribute driving. When executed by a processor, the built-in SQL function logic error detection program based on function attribute driving implements the built-in SQL function logic error detection method based on function attribute driving as described above.

[0021] To achieve the above objectives, a third aspect of the present invention provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described method for detecting logical errors in built-in SQL functions based on function attributes.

[0022] To achieve the above objectives, a fourth aspect of the present invention proposes a built-in SQL function logical error detection device based on function attribute driving, comprising: an acquisition module for acquiring a set of built-in SQL functions; a model building module for constructing a triplet model for each function in the built-in SQL function set to obtain a built-in SQL function model library, wherein each built-in SQL function model includes signature, constraint, and attribute information; a first query generation module for generating function expressions based on the built-in SQL function model library and embedding them into rich context SQL statements to obtain an original SQL query set; a second query generation module for parsing the original SQL query set into an abstract syntax tree and traversing the abstract syntax tree to locate function nodes, thereby constructing a variant SQL query set through function transformations applied by function intra-function or inter-function transformations; and a logical error detection module for comparing the results of the original SQL query set and the variant SQL query set to detect whether there are built-in SQL functions with logical errors.

[0023] The above-mentioned method for detecting logical errors in built-in SQL functions based on function attributes has the following advantages: by constructing a formal model for built-in SQL functions that includes signatures, constraints, and semantic attributes, generating rich-context test queries that embed the target function, and constructing equivalent mutation queries based on the semantic attributes of the function, and using cross-query attribute consistency as a test oracle, the method achieves efficient and accurate detection of logical errors in built-in SQL functions, effectively covering existing unidentifiable defects at the function implementation level. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a built-in SQL function logic error detection method based on function attribute driving according to an embodiment of the present invention.

[0025] Figure 2 This is a schematic diagram of the end-to-end workflow of the built-in SQL function logic error detection method based on function attribute driving according to an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of the implementation architecture according to an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of a built-in SQL function logic error detection device based on function attribute driving according to an embodiment of the present invention. Detailed Implementation

[0028] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0029] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present invention and to fully convey the scope of the invention to those skilled in the art.

[0030] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0031] refer to Figure 1 As shown, the built-in SQL function logic error detection method based on function attribute driving according to an embodiment of the present invention includes the following steps:

[0032] S101, retrieve the built-in SQL function set.

[0033] As an example, by mining the documentation and test cases of the target database management system, a complete list of all built-in SQL functions supported by that version can be compiled, covering all categories such as mathematics, strings, date and time, type conversion, aggregation, and conditional functions. Then, basic information such as the calling rules, parameter / return type definitions, valid input range, and dialect characteristics of each function can be extracted to obtain the set of built-in SQL functions.

[0034] S102, construct a triplet model for each function in the built-in SQL function set to obtain the built-in SQL function model library, wherein each built-in SQL function model includes signature, constraint and attribute information.

[0035] As an example, the built-in SQL function model is constructed based on the following formula:

[0036]

[0037] Where f represents a built-in SQL function, This represents the callable interface of f, which enumerates all overloaded versions of its functions. Each overload includes the function name, category, number of parameters, data type of each parameter, and return type. This represents the semantic constraints required for the effective execution of the record, which defines parameter semantic constraints for each overloaded version; This represents the function properties used to instantiate transformations, including intra-function properties and inter-function properties.

[0038] Specifically, an explicit function model is constructed for built-in SQL functions to support: (i) type-correct generation and context-aware embedded function expressions, and (ii) attribute-driven transformations with a verifiable semantic oracle. For each built-in SQL function f, the model consists of three parts: signature, constraints, and attributes. These parts will be formally described below, with concrete examples provided.

[0039] Define signature:

[0040] The function signature is represented as: Where name represents the function identifier, kind represents the function category (such as aggregate functions), and k represents the number of elements. Indicates parameter type requirements. Indicates the return type. Built-in SQL functions may have multiple overloaded functions, and their overload set is represented as follows: For variable functions, they are modeled as a finite family of overloaded functions by instantiating k within a limited scope.

[0041] This signature-based modeling serves a dual purpose: first, it transforms the type constraints of function calls in a Database Management System (DBMS) into explicitly inspectable specifications (including parameter types and return types); second, it unifies overloaded functions and variable functions into a single representation, enabling them to be checked from... Choose a signature to enumerate valid call formats.

[0042] Example (CONCAT overload): CONCAT can be modeled as a family of scalar overloads with different orders. For example, two overloads. CONCAT,scalar,1,(String),String and CONCAT,scalar,3,(String,String,String),String It can instantiate CONCAT with different numbers of string parameters while maintaining the correct calling type.

[0043] Define constraints:

[0044] Many functions impose semantic constraints in addition to type correctness (such as valid input range or special parameter restrictions). These requirements can be modeled as predicates of parameter expressions.

[0045] For those with selected overload The built-in SQL function f, let its parameter expression be... ,in, Represents the expression for the i-th parameter; Associated with a (potentially empty) list of parameterized constraints:

[0046]

[0047] in, This represents a list of constraints for parameters 1 through k. Either (No additional restrictions), or Predicates and function calls It is acceptable if all non-null constraints are satisfied:

[0048]

[0049] Where k represents the selected function overload. The fixed number of parameters, V represents a vector consisting of all concrete parameter expressions, and holds represents the predicate satisfaction states. In the model, constraints are used to capture the semantic premises required for efficient evaluation beyond type correctness. For the selected overload... Only when its parameter expression satisfies A function call is considered acceptable only if all predicates in the function call are present.

[0050] Example (DATE_FORMAT constraint): For scalar overload The constraints are modeled as a list of parameters.

[0051]

[0052] The first parameter has no additional restrictions, while the second parameter must satisfy the format template constraints:

[0053]

[0054] in, The second argument to DATE_FORMAT represents the syntax specification for a valid format template, which is a string consisting of literal characters and format specifiers (such as %Y, %m, %d, %H, %i, and %s). This constraint stipulates that the second argument to DATE_FORMAT must be a template string of the format specification, not an arbitrary string.

[0055] Define attributes:

[0056] Function properties describe the semantic characteristics of built-in SQL functions, providing a standardized foundation for constructing attribute equivalence expressions. Properties are typically associated with a specific overloaded function and may only constrain some of its parameters (e.g., the symmetry of a parameter or the commutativity between two parameters). Furthermore, some properties involve multiple functions (such as inverse operations), characteristics that cannot be expressed by a single function specification. Therefore, protected equivalence templates at the expression level are used to model properties.

[0057] Attributes are represented in the form of a protected equivalent template:

[0058]

[0059] in, This represents a set of one or more overloaded signatures related to this attribute. This indicates the position of the parameter that is constrained by this attribute for each related signature. Indicates the preconditions for applicability. yes The next two properties are equivalent expressions.

[0060] Property templates are divided into two categories. Properties within a function contain only a single overload signature. This is used to describe equivalence relations (such as symmetry and idempotency) within the same function. Function-to-function properties contain multiple overload signatures. Used to describe equivalence relations across functions (such as inverse operations). For a built-in SQL function f, its attribute template set is denoted as... This may include templates that reference other functions to handle inter-function situations.

[0061] Example (odd symmetry of ASIN): for scalar overload The odd symmetry property is modeled as an internal template of the function, and its =1:

[0062]

[0063] Example (Inverse operation characteristics of EXP and LOG): Let = and = LOG, scalar, 1, (numerical value), numerical value The inverse operation property is modeled using inter-function templates:

[0064]

[0065] This property modeling only specifies when two expressions are semantically equivalent under preset conditions.

[0066] S103 generates function expressions based on the built-in SQL function model library and embeds them into rich context SQL statements to obtain the original SQL query set.

[0067] As an example, generating function expressions based on the built-in SQL function model library and embedding them into rich-context SQL statements to obtain the original SQL query set includes: selecting and instantiating a query skeleton with expression slots, and deriving slot constraint contracts from surrounding sentences to determine the expected return type and allowed function types of the slots; sampling target functions from the target function set and assigning them to slots, and obtaining overloaded signatures for compatible slots from the signature set of target functions; obtaining a list of parameter constraints for the overloaded signatures from the built-in SQL function model, and calling parameter generation logic for each parameter position to construct a compliant expression to combine all parameter expressions into a parameter vector; constructing the complete expression of the target function based on the parameter vector, and replacing the placeholder slots in the query skeleton with the complete expression to obtain the original SQL query.

[0068] In other words, given a set of functions F to be tested, the original query is synthesized iteratively: first, a context-rich query framework is selected, and then its expression slots are filled with allowed functional expressions. Each embedded call is based on a function model. Instantiation: Ensure type correctness (allowed types, atoms, parameter / return types), and This provides acceptable predicates, which are injected into the query to ensure semantically valid evaluation.

[0069] Table 1 shows the algorithm for embedding the objective function into a context-rich SQL query:

[0070]

[0071] As shown in Table 1 above, an executable raw query is synthesized by embedding the target built-in function into a context-rich SQL skeleton under the guidance of the function model. First, a query skeleton T with expression slot F is selected and instantiated, and slot contracts are derived from the surrounding clauses. This is to determine the expected return type of s and the allowed function types (lines 1-4). Then, the objective function f is sampled from F, and a compatible overloaded signature is selected. Its type and return type satisfy the slot contract, and are based on the parameter type ( Instantiate the call parameters (lines 5-9). For each parameter position i, PickExpr constructs a candidate pool Ω containing (i) well-typed columns in the visible scope, (ii) typed literals, (iii) derived expressions, and (iv) return types. Nested function calls, then sampling expressions from Ω. (Lines 10-16). Importantly, PickExpr checks constraints during the generation process: for the i-th parameter, it continuously resamples candidate expressions until the corresponding constraint is reached. The constraint is satisfied (or undefined, i.e.) = After all parameters are instantiated, the algorithm forms the function expression E = Fill slots s with E and output the finalized query Q (lines 17-18).

[0072] Table 2 shows a simple example of embedding the objective function into a context-rich SQL query:

[0073]

[0074] As shown in Table 2 above, the algorithm first creates a query skeleton with expression slots (such as SLOT1 and SLOT2), which serve as placeholders for the functions to be embedded. The algorithm then analyzes the query context and selects an appropriate function for each slot. In this case, SLOT1 can be filled with any function (DATE_FORMAT was randomly selected), while SLOT2, which requires a scalar function, is filled with ASIN. After selecting the function, the algorithm verifies the validity of each function parameter: the first parameter of DATE_FORMAT must be a DateTime column, and the second parameter must be a string representing the date format (such as 'YYYY-MM-DD'); ASIN requires the parameter to be a numeric column. After confirming that the parameters meet the type and semantic constraints, the algorithm constructs the function call and inserts it into the corresponding slot, ultimately generating a complete query statement.

[0075] S104 parses the original SQL query set into an abstract syntax tree, and traverses the abstract syntax tree to locate function nodes, so as to construct a mutated SQL query set by applying function transformation through intra-function transformation or inter-function transformation.

[0076] As an example, the original SQL query set is parsed into an abstract syntax tree, and the abstract syntax tree is traversed to locate function nodes. A mutated SQL query set is then constructed by applying function transformations through intra-function or inter-function conversions. This includes: parsing the original SQL query set into an abstract syntax tree and traversing to locate all target function nodes; matching the corresponding attribute template for each target function node and selecting an applicable transformation rule to obtain the target function expression. The transformation rules include intra-function and inter-function conversions. Intra-function conversions directly replace expressions based on single-function attribute substitutions, while inter-function conversions replace expressions based on cross-function equivalence relations. The remaining structure of the original SQL query is preserved, and only the target function expression is replaced to generate attribute-equivalent mutated SQL queries.

[0077] It should be noted that the semantic features of built-in SQL functions are used to generate attribute equivalent transformations, and then logical errors are detected by comparing the results of the original query and the mutated query.

[0078] The conversion rules are as follows: based on the nature of the function attributes, the conversion rules are divided into intra-function conversions and inter-function conversions. These conversion rules are directly derived from the attribute templates defined above. The specific application scope depends on the attribute type and may apply to a single function expression or multiple functions. For ease of understanding, func is represented as the overload signature, and x represents the function attribute parameter associated with that signature.

[0079] Table 3 shows the rules for function attribute conversion:

[0080]

[0081] Table 3 above details the various conversion rules and their applicable function expressions. It's important to note that the notation func(x) does not mean the SQL function accepts only one parameter, but rather that the SQL function exhibits this property with respect to the parameter x, consistent with the attribute definition.

[0082] Specifically, intra-function transformations directly apply the properties to a single function, such as transforming SIN(x) based on the properties of odd functions. SIN ( The conversion between functions involves relationships between multiple functions; for example, using the invertible properties of exponential and logarithmic functions, LN(EXP(x)) can be converted to x. It is scalable, allowing the addition of new function properties and conversion rules.

[0083] The mutation process generates mutated queries through a transformation system based on function expression attributes. The specific steps include: first, parsing the original SQL query into an Abstract Syntax Tree (AST) and identifying relevant function expressions; then, FPMT selects appropriate function attributes and applies predefined transformation rules to generate attribute-equivalent expressions; finally, embedding the transformed expression into the original query, replacing the function call portion, while leaving the rest unchanged. This method applies mutation to function expressions, enabling accurate detection of logical errors without interfering with other query components.

[0084] S105 is a built-in SQL function that compares the results of the original SQL query set and the modified SQL query set to detect the presence of logical errors.

[0085] As an example, a built-in SQL function that compares the results of the original SQL query set and the variant SQL query set to detect whether there is a logical error includes: if the query results of the original SQL query set and the variant SQL query set are completely consistent, then it is determined that there is no logical error; if the query results of the original SQL query set and the variant SQL query set are different, then it is determined that there is a logical error.

[0086] Therefore, as Figure 2 As shown, this paper verifies the behavior of a large number of built-in SQL functions when interacting with surrounding operators in the context of SQL queries. First, a model is built for each function through function modeling, summarizing its characteristics, constraints, and properties. Based on these models, function expressions are generated, embedded into rich-context SQL statements, and synthesized into the original query. Then, the query abstract syntax tree (AST) is traversed to locate function nodes, and function transformations are applied through intra-function or inter-function transformations to construct mutated queries. Finally, the original query and the mutated query are executed, and the results are compared; the output differences can expose potential errors.

[0087] In addition, such as Figure 3 As shown, the specific implementation details are as follows: A fully automated tool was developed based on ValScope, mainly used for generating databases and complex queries. The tool's codebase contains 17,970 lines of Python code, of which 2,980 lines are used to implement the methods of this application. Figure 3 Its architecture has been demonstrated. Key implementation details will be explained in detail below.

[0088] Test Case Generation: In the preparation phase, each built-in SQL function to be tested is first modeled, using the method described above. Six database management systems are supported, including 95 functions for MySQL, 92 functions for MariaDB, 86 functions for OceanBase, 95 functions for Percona, 91 functions for PolarDB, and 76 functions for TiDB. These functions cover multiple categories, including mathematical functions, string manipulation functions, date / time manipulation functions, type conversion functions, and conditional functions. All pre-built function models are stored in a function knowledge base.

[0089] These function models are then used to guide the generation of the original and variant queries. In the original query generation phase, ValScope is used to generate rich-context queries with SQL slots. ValScope is an Abstract Syntax Tree (AST)-based SQL query generator whose dependency analysis component offers superior accuracy. Compared to existing tools like SQLSmith and Go-randgen, it demonstrates better semantic accuracy when handling complex queries with multiple nested subqueries. After generating these rich-context queries, functions are selected from a function knowledge base to embed queries, ultimately forming the original query. It's important to note that this precise function modeling approach supports complex query structures (especially nested functions) while avoiding the introduction of semantic errors.

[0090] Function Transformation: As mentioned above, the original query is first parsed using SQLGlot, which generates an AST of the original query using the same context-free grammar as the seed query, for mutation. Then, each function node is traversed, its overloaded functions are extracted, and matched against a pre-built model in the function knowledge base. Next, a transformation rule is randomly selected to apply mutation to the original query.

[0091] Results Comparison: The execution results of the mutated query and the original query were compared and analyzed, including the query output and the database changes triggered as a result. If differences are found, it indicates the presence of a logical error.

[0092] Defect Report Generation Process: To avoid duplicate defect report submissions and improve the understandability of test results, SQLess is first used to simplify defects and accurately pinpoint their root causes. Simultaneously, duplicate entries are removed following Pinolo's research methodology. The final simplified original query, variant query, and defect description submitted to the development team for confirmation will serve as the standard submission materials.

[0093] Versatility: This application demonstrates excellent versatility in testing built-in SQL functions, adapting to various database management system testing tools, SQL dialects, and query structures. First, once the function model is built, it can be seamlessly integrated with any database management system testing tool. Once the model of the target SQL function is determined, it can be embedded into any testing framework for verification. Second, it can simulate functions of different SQL dialects. Through the function modeling process, functions of different SQL dialects can be represented based on function signatures, constraints, and attributes, thus adapting to various database management system dialects. Finally, it also demonstrates versatility in handling different query structures. Because the test oracle is based on function expression-level transformations rather than global query structures, this method remains efficient in handling queries of varying complexity, maintaining effectiveness regardless of the query format.

[0094] Scalability: This application fully considers scalability, seamlessly adapting to different database management systems (DBMS) and supporting a variety of SQL functions. Extending this application to new DBMSs requires minimal work—simply implementing the target DBMS's connection interface and function model, typically completed in just 2 hours. In addition to the seven attributes and their corresponding conversion rules mentioned in this application, it can be easily extended to support more function attributes and conversion rules. This is achieved simply by adding new attributes and their associated conversion rules to the function model, making it highly adaptable to new function behaviors.

[0095] Black-box testing: The method described in this application is a black-box testing technique that does not rely on the internal implementation of the database management system (DBMS) under test. This characteristic makes the method highly portable, enabling easy deployment for testing various DBMS systems, including those whose source code is inaccessible.

[0096] In summary, the built-in SQL function logic error detection method based on function attribute driving according to embodiments of the present invention effectively discovers vulnerabilities that are difficult to detect by existing testing techniques by analyzing the semantic characteristics of functions and generating attribute-equivalent queries. Evaluation results on multiple database management systems show that the built-in SQL function logic error detection method based on function attribute driving can discover previously unknown logic errors, highlighting its potential to improve the reliability of SQL function implementations.

[0097] In addition, the present invention also proposes a computer-readable storage medium storing a built-in SQL function logic error detection program based on function attribute driving. When the built-in SQL function logic error detection program based on function attribute driving is executed by a processor, it implements the built-in SQL function logic error detection method based on function attribute driving as described above.

[0098] In addition, this invention also proposes a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described method for detecting logical errors in built-in SQL functions based on function attributes.

[0099] Figure 4 This is a block diagram of a built-in SQL function logic error detection device based on function attribute driving according to an embodiment of the present invention. Figure 4 As shown, the logic error detection device includes: an acquisition module 10, a model building module 20, a first query generation module 30, a second query generation module 40, and a logic error detection module 50;

[0100] The module includes: an acquisition module 10 for acquiring a set of built-in SQL functions; a model building module 20 for building a triplet model for each function in the built-in SQL function set to obtain a library of built-in SQL function models, where each built-in SQL function model includes signature, constraints, and attribute information; a first query generation module 30 for generating function expressions based on the library of built-in SQL function models and embedding them into rich-context SQL statements to obtain a set of original SQL queries; a second query generation module 40 for parsing the original SQL query set into an abstract syntax tree and traversing the abstract syntax tree to locate function nodes, so as to construct a set of variant SQL queries by applying function transformations through intra-function or inter-function transformations; and a logic error detection module 50 for comparing the results of the original SQL query set and the variant SQL query set to detect whether there are any built-in SQL functions with logical errors.

[0101] It should be noted that the explanation of the above-described embodiment of the built-in SQL function logic error detection method based on function attribute driving is also applicable to the built-in SQL function logic error detection device based on function attribute driving in this embodiment, and will not be repeated here.

[0102] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0103] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0104] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a processFigure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0106] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0107] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0108] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0109] In the description of this invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0110] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0111] In this invention, unless otherwise explicitly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "over," and "on top" of the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

[0112] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms should not be construed as necessarily referring to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0113] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for detecting logical errors in built-in SQL functions based on function attributes, characterized in that, Includes the following steps: Retrieve the built-in SQL function set; For each function in the built-in SQL function set, a triplet model is constructed to obtain a built-in SQL function model library, wherein each built-in SQL function model includes signature, constraint and attribute information; The function expression is generated based on the built-in SQL function model library and embedded into the rich context SQL statement to obtain the original SQL query set; The original SQL query set is parsed into an abstract syntax tree, and the abstract syntax tree is traversed to locate function nodes, so as to construct a variant SQL query set by applying function transformation through intra-function transformation or inter-function transformation. The results of the original SQL query set and the mutated SQL query set are compared to detect whether there are any built-in SQL functions with logical errors. Specifically, function expressions are generated based on the built-in SQL function model library and embedded into rich-context SQL statements to obtain the original SQL query set, including: Select and instantiate the query skeleton with expression slots, and deduce the slot constraint contract from the surrounding sentences to determine the expected return type of the slot and the allowed function types; Sample target functions from the target function set and assign them to slots, and obtain overloaded signatures compatible with the slots from the signature set of the target functions; The parameter constraint list of the overloaded signature is obtained from the built-in SQL function model, and the parameter generation logic is called for each parameter position to construct an expression that meets the requirements, so as to combine all parameter expressions into a parameter vector. Construct a complete expression for the objective function based on the parameter vector, and replace the placeholder slots in the query skeleton with the complete expression to obtain the original SQL query.

2. The built-in SQL function logic error detection method based on function attribute driving as described in claim 1, characterized in that, Construct a built-in SQL function model based on the following formula: Where f represents a built-in SQL function, This represents the callable interface of f, which enumerates all overloaded versions of its functions. Each overload includes the function name, category, number of parameters, data type of each parameter, and return type. This represents the semantic constraints required for the effective execution of the record, which defines parameter semantic constraints for each overloaded version; This represents the function properties used to instantiate transformations, including intra-function properties and inter-function properties.

3. The built-in SQL function logic error detection method based on function attribute driving as described in claim 1, characterized in that, The original SQL query set is parsed into an abstract syntax tree, and the abstract syntax tree is traversed to locate function nodes. This allows for the application of function transformations through intra-function or inter-function conversions to construct a mutated SQL query set, including: The original SQL query set is parsed into an abstract syntax tree, and all target function nodes are located by traversing it. For each target function node, match the corresponding attribute template and select the applicable transformation rule to obtain the target function expression. The transformation rule includes intra-function transformation and inter-function transformation. Intra-function transformation is based on replacing the expression with a single function attribute, while inter-function transformation is based on replacing the expression with a cross-function equivalence relation. Keeping the rest of the original SQL query unchanged, only the target function expression is replaced to generate a variant SQL query with equivalent attributes.

4. The built-in SQL function logic error detection method based on function attribute driving as described in claim 1, characterized in that, Built-in SQL functions that compare the results of the original SQL query set and the mutated SQL query set to detect the presence of logical errors include: If the query results of the original SQL query set and the mutated SQL query set are completely consistent, then it is determined that there is no logical error; If the query results of the original SQL query set and the mutated SQL query set differ, then a logical error is determined to exist.

5. A computer-readable storage medium, characterized in that, It stores a built-in SQL function logic error detection program based on function attribute driving. When the built-in SQL function logic error detection program based on function attribute driving is executed by the processor, it implements the built-in SQL function logic error detection method based on function attribute driving as described in any one of claims 1-4.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the built-in SQL function logic error detection method based on function attribute driving as described in any one of claims 1-4.

7. A built-in SQL function logic error detection device based on function attribute driving, characterized in that, include: The retrieval module is used to retrieve the built-in SQL function set; The model building module is used to build a triplet model for each function in the built-in SQL function set to obtain a built-in SQL function model library, wherein each built-in SQL function model includes signature, constraint and attribute information; The first query generation module is used to generate function expressions based on the built-in SQL function model library and embed them into rich context SQL statements to obtain the original SQL query set. The second query generation module is used to parse the original SQL query set into an abstract syntax tree, and traverse the abstract syntax tree to locate function nodes, so as to construct a variant SQL query set by applying function transformation through intra-function transformation or inter-function transformation. The logical error detection module is used to compare the results of the original SQL query set and the mutated SQL query set to detect whether there are any built-in SQL functions with logical errors. The first query generation module is also used for: Select and instantiate the query skeleton with expression slots, and deduce the slot constraint contract from the surrounding sentences to determine the expected return type of the slot and the allowed function types; Sample target functions from the target function set and assign them to slots, and obtain overloaded signatures compatible with the slots from the signature set of the target functions; The parameter constraint list of the overloaded signature is obtained from the built-in SQL function model, and the parameter generation logic is called for each parameter position to construct an expression that meets the requirements, so as to combine all parameter expressions into a parameter vector. Construct a complete expression for the objective function based on the parameter vector, and replace the placeholder slots in the query skeleton with the complete expression to obtain the original SQL query.

Images