Matrix user right index implementation method, system and electronic equipment on PostgreSQL

Abstract

The application discloses a kind of matrix user authority index implementation method and system on PostgreSQL, method includes: according to the relationship between the organization structure of system and user and data, establish matrix data model, the matrix data model includes user authority matrix and data attribution matrix;According to the extraction rule of preestablished, user authority matrix and data attribution matrix are extracted respectively, and user authority secret key and data attribution unit are obtained;According to the comparison rule of preestablished, each user authority secret key is compared with all data attribution units one by one, and the user data list corresponding to each user authority secret key is obtained;According to all user authority secret key and the user data list corresponding thereto, form GIN index storage structure;Add matrix data type in PostgreSQL, and construct the operator corresponding to matrix data type;Define the support function required by GIN index, realize GIN index based on operator and support function.

Description

Technical Field

[0001] The present invention relates to PostgreSQL, a PostgreSQL operator, and a PostgreSQL index, and in particular to a method and system for implementing an index of matrix user permissions on PostgreSQL. Background Art

[0002] PostgreSQL is an open source object-relational database system. As the amount of data stored in the database grows and the data types become more complex, querying certain data based on conditions becomes cumbersome and the query speed decreases.

[0003] The above problem can be solved by using indexes in PostgreSQL. An index is a data structure that stores database data using a specific data structure algorithm. Establishing a suitable index can help us quickly retrieve data from the database and quickly locate records that may meet the requirements without having to traverse all records.

[0004] Currently, PostgreSQL supports B-tree, Hash, GiST, SP-GiST, GIN, and BRIN index types. Each index type has different application scenarios. For example, B-tree is primarily used for equality and range queries on sortable data. When using operators such as <<==>=>, consider using a B-tree index for data queries. A hash index stores the hash value of the indexed field VALUE and only supports equality queries. GIN (Generalized Inverted Index) is an index structure that stores a set of (key, posting list) pairs. It currently supports data types such as arrays and full-text searches.

[0005] As the business continues to develop, the system's control over user permissions has become increasingly refined. For example, in the self-study exam business, users can be divided into students, teachers, and administrators, with administrators divided into six levels: school, site, teaching point, major, grade, and class. It's easy for students to know whether a student has permission to operate on a certain piece of data, because the relationship between students and data is one-to-one, and students can only operate on data related to themselves. PostgreSQL can use the = operator and B-tree indexes to quickly find the corresponding data. For teachers, a teacher can manage multiple classes, and a piece of data can belong to multiple classes. The relationship between users and data is many-to-many, and data authorization can be stored in the form of an array. PostgreSQL can use the && operator and GIN indexes to quickly find the corresponding data.

[0006] Students and teachers can quickly find data based on the operators and indexes provided by PostgreSQL. However, administrators have multiple roles, and different roles have hierarchical relationships. For example, there is a user in the system who is both the site administrator of 1 school and 1 site, and the teaching point administrator of 2 schools, 1 site, and 1 teaching point. This can be represented by a matrix: For such a matrix user, we want to know which data he has operation permissions for. PostgreSQL does not have suitable operators or index methods that support matrix data types to handle the relationship between users and data.

[0007] Therefore, the present invention provides a custom operator and an indexing method that can support matrix data types to solve the above problems. Summary of the Invention

[0008] To overcome the above-mentioned deficiencies in the prior art, the present invention provides a method and system for implementing matrix user permission indexing on PostgreSQL, to solve at least one of the above-mentioned technical problems.

[0009] According to one aspect of the present invention, a method for implementing an index of matrix user permissions on PostgreSQL is provided, comprising: constructing an operator to implement matrix data conversion, and storing the converted matrix data based on a GIN index;

[0010] The construction of the operator to realize the conversion of matrix data further includes:

[0011] According to the organizational structure of the system and the relationship between users and data, a matrix data model is established, wherein the matrix data model includes a user authority matrix and a data ownership matrix;

[0012] According to the preset extraction rules, the user authority matrix and the data attribution matrix are extracted row by row to obtain the user authority key and the data attribution unit;

[0013] According to the preset comparison rules, each user authority key is compared with all data attribution units one by one to obtain each user authority key and the corresponding user data list;

[0014] A GIN index storage structure is formed based on all user permission keys and the corresponding user data list;

[0015] The storage of the converted matrix data is implemented based on the GIN index, further including:

[0016] Add a matrix data type to PostgreSQL and build operators corresponding to the matrix data type;

[0017] Define the five support functions required for GIN indexes and implement the indexing of the GIN index storage structure based on operators and support functions.

[0018] The above technical solution constructs operators to handle the relationship between matrix data and extends an access method that supports matrix data types based on GIN indexes to realize the storage of matrix data, thereby realizing fast indexing of matrix data under the GIN framework, solving the problem that matrix users find it difficult to determine which data they have operation permissions to.

[0019] A matrix user refers to a user that corresponds to multiple nodes, has permissions on multiple nodes, and each node generates a large amount of usage data. The user permission data and the usage data generated by the user are represented by a matrix.

[0020] Because each node generates a large amount of data during system operation, storage space requirements are high. Furthermore, existing methods for querying the permissions of a matrix user require a large number of indexes and computational overhead, making it difficult to quickly determine which data the user has permission to operate on. Therefore, this invention constructs custom operators to extract and compare system data according to preset logic, resulting in a storage structure suitable for GIN indexing. Next, within the GIN framework, this method imports matrix data by adding a matrix data type and constructing corresponding operators. Furthermore, the five support functions required for GIN indexing are defined, and semantic parsing of the imported and stored matrix data is performed, thus enabling GIN index storage of matrix data.

[0021] As a further technical solution, the system's organizational structure includes six levels of organizational nodes: school, site, teaching point, major, grade, and class. Among them, each row of the user authority matrix corresponds to a piece of permission data of the user, and each column corresponds to an organizational node; each row of the data ownership matrix corresponds to the ownership of a piece of data, and each column corresponds to an organizational node.

[0022] For the data attribution matrix, its data can be usage data generated by students, teachers or administrators, or resource data uploaded by students, teachers or administrators. Regardless of the usage data generated in the process or the uploaded resource data, there is a relationship in which one piece of data belongs to multiple nodes. For example, if a student attends two classes, then the usage data generated by the student has an attribution relationship with the two class nodes. It belongs to both the data of class A and the data of class B. Therefore, in the data attribution matrix, each row of the matrix is ​​represented as the attribution of a piece of data, indicating that it is mounted under this attribution relationship.

[0023] Furthermore, resource data, such as course resource data uploaded by administrators, is shared by multiple schools or sites and is mounted under multiple organizational nodes. Therefore, each row of this resource data matrix represents the ownership data mounted on an organizational node.

[0024] In existing teaching management systems, the organizational structure has multiple layers of organizational nodes, and administrators often manage multiple organizational nodes. This creates a many-to-many relationship between multiple administrators and multiple organizational nodes. This many-to-many relationship is more suited to a matrix structure. Furthermore, separating user permission data from user usage data and constructing different matrix structures facilitates user permission management.

[0025] As a further technical solution, the six-level organizational nodes of school, site, teaching point, major, grade, and class are abstractly represented as A, B, C, D, E, and F respectively, and each row in the user authority matrix and the user data matrix is ​​represented as AaBbCcDdEeFf, where a represents the school number, b represents the site number, c represents the teaching point number, d represents the major number, e represents the grade number, and f represents the class number; and a matrix data model is constructed based on the user's authority at each organizational node and the data generated by the user at each organizational node.

[0026] This abstraction transforms matrix data into columns of abstract data, reducing storage space. Furthermore, the abstracted data maintains a consistent format, facilitating logical operations using operators and enabling rapid conversion of matrix data.

[0027] As a further technical solution, for the user authority matrix, the extraction rule is: if the user has authority in a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the authority data of each row of the user authority matrix is ​​obtained.

[0028] As a further technical solution, for the data attribution matrix, the extraction rule is: if the user generates data at a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the attribution data of each row of the data attribution matrix is ​​obtained.

[0029] By extracting matrix data row by row, each row of the user permission matrix corresponds to a row of permission data, and each row of the data attribution matrix corresponds to a row of attribution data. The format of the permission data and the attribution data are the same. The user's user permissions on each node can be judged through data comparison, thereby achieving fast query of user permissions with less computing overhead and a better number of indexes.

[0030] As a further technical solution, each row of the matrix is ​​defined as ending with zero and represented by the letter Z. The extracted permission data and attribution data are then processed to zero, resulting in a simplified user permission key and data attribution unit. This technical solution further simplifies the extracted permission data and user usage data.

[0031] As a further technical solution, the user authority matrix and the data attribution matrix are extracted row by row to obtain the user authority keys and data attribution units represented by rows. The user authority keys and data attribution units are compared pairwise. If the comparison result is True, True is returned, otherwise False is returned.

[0032] Specifically, the comparison rules include three: First, if the comparison is different, it is False; Second, when comparing the user authority key and the data attribution unit, if any of them encounters the end character Z, the comparison is stopped and the result before the end is used as the final result; Third, if there are multiple results when comparing a user authority key with all the data attribution units in a data attribution matrix, the multiple results are in an OR relationship.

[0033] According to the above three comparison rules, the user permission data and the user usage data are compared one by one to obtain the permission data corresponding to each user permission data, so that when indexing, by inputting the user permission data, the user usage data corresponding to the permission can be directly obtained.

[0034] As a further technical solution, the GIN index storage structure is [Key, Postinglist], where Key represents the user authority key and Postinglist represents the user data list corresponding to the user authority key.

[0035] According to one aspect of the present invention, a system for implementing a matrix user permission index on PostgreSQL is provided, comprising:

[0036] A matrix data model building module is used to build a matrix data model based on the system's organizational structure and the relationship between users and data. The matrix data model includes a user authority matrix and a data ownership matrix.

[0037] The data extraction module is used to extract the user authority matrix and the data attribution matrix row by row according to the preset extraction rules to obtain the user authority key and the data attribution unit;

[0038] The data comparison module is used to compare each user authority key with all data attribution units one by one according to the preset comparison rules, and obtain a list of each user authority key and the corresponding user data;

[0039] The data formation module is used to form a GIN index storage structure based on all user permission keys and the corresponding user data list;

[0040] The GIN extension module adds a matrix data type to PostgreSQL and builds operators corresponding to the matrix data type.

[0041] The index module defines the five support functions required for GIN indexes and implements indexing of the GIN index storage structure based on operators and support functions.

[0042] The constructed GIN index storage pair is stored according to the GIN index to implement the GIN index.

[0043] According to one aspect of the present invention, an electronic device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, at least one program, or the code set or instruction set is loaded and executed by the processor to implement the method for implementing an index of matrix user permissions on PostgreSQL as described in any one of claims 1 to 8.

[0044] Compared with the prior art, the present invention has the following beneficial effects:

[0045] (1) The present invention constructs operators to process the relationship between matrix data and extends an access method that supports matrix data types based on the GIN index to realize the storage of matrix data, thereby achieving fast indexing of matrix data under the GIN framework, solving the problem that matrix users find it difficult to determine which data they have operation permissions for.

[0046] (2) The present invention adds a new operator based on the original PostgreSQL operator, which makes up for the shortcoming that the PostgreSQL operator cannot compare matrix data types.

[0047] (3) The present invention adds a matrix data type based on the GIN index, so that data of the matrix data type can also be stored according to the GIN index.

[0048] (4) The present invention can greatly improve the data query speed, optimize the storage space, reduce the number of indexes, and reduce the computing overhead through the new index access method. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 2 is an abstract diagram of a data model according to an embodiment of the present invention.

[0050] Figure 2A data posting list integration schematic diagram according to an embodiment of the present application.

[0051] Figure 3 An index extension flowchart according to an embodiment of the present application. DETAILED DESCRIPTION

[0052] The technical solutions of the embodiments of the present application will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of the present application.

[0053] The present application discloses a matrix user permission index implementation method on PostgreSQL. The method mainly includes implementation of an operator internal algorithm and implementation of an index.

[0054] An operator is necessary for SQL statement to find and process data. Therefore, the present application defines an operator to process the relationship of the matrix data type.

[0055] The construction of the operator specifically includes:

[0056] 1. Establish a data model

[0057] According to the organizational structure (school, site, teaching point, major, grade, class) of the system and the relationship between the user and the data, a data model is established. The data model is the cornerstone of the logic of the operator internal algorithm.

[0058] According to the business requirements, the organizational structure in the system is divided into six layers, which are school, site, teaching point, major, grade, and class. As shown in the figure, the six-layer organizational structure is abstracted into letters A, B, C, D, E, and F. Each piece of data in the system is mounted to the six-layer organizational structure. Figure 1

[0059] For example, the user u2 in the figure is both the site administrator of the 1 school 2 site and the teaching point administrator of the 1 school 1 site 1 teaching point. The user u2 is represented by a matrix as Figure 1 The data mounted to the organizational structure can be represented as A1B2C0D0E0F0 and A1B1C1D0E0F0. Actually, the data A1B2C0D0E0F0 is mounted to the 1 school 2 site, and ends at the site. Therefore, we define that the matrix data encounters 0 to end and is represented by the letter Z. Finally, the user u2 can be abstracted as A1B2Z and A1B1C1Z.

[0060] ​​Following this approach, we represent all user information and other data in this format. We use the abstracted user permissions data as keys (e.g., A1B2Z) and group all data belonging to these permissions together as posting lists. (This is based on the GIN inverted index extension, an index structure that stores (key, posting list) pairs.) At this point, we have abstracted all data into the (key, posting list) format.

[0061] 2. Custom operator internal logic algorithm

[0062] Implement the internal logic algorithm of the operator according to the data model. For example, in the data model and We define the operator ~ to calculate the relationship between two matrices A and B, which can be expressed as A~B. The algorithm is mainly used to process relationships similar to those between matrices A and B. The relationship types handled by the algorithm include greater than, less than, and contained.

[0063] like Figure 2 The figure below uses user permission data A1Z as a key to illustrate how to find the corresponding Posting List set through comparison. The comparison is based on three main rules. The first rule is that any difference is considered False. For example, if A1Z and data d3 (A2B1Z) are not equal to A2, the comparison stops immediately and the result is False. The second rule is that if either of the two data points encounters the end character Z, the comparison stops, and the result before the end is used as the final result. For example, if A1Z and data d4 (A1B1C1Z) have the first digit A1 equal to A1, the comparison is True. If the second digit is Z, the comparison stops, and the final result is True. The third rule is that if there are multiple results for a data point, they are compared in an OR relationship. For example, if the comparison results of data d1, A1Z and data d1 are T, F, T, T, T, the final result is True. Based on these three rules, I found that the Posting Lists corresponding to A1Z are d1, d2, and d4. These three rules are also the basic basis of the operator's internal comparison algorithm.

[0064] An index is a distributed storage structure created to speed up the retrieval of rows in a table. The present invention extends a matrix indexing method based on the GIN inverted index.

[0065] like Figure 3 As shown in the figure, the matrix indexing method based on GIN inverted index is mainly divided into three steps:

[0066] 1. Adding a new data type: A new matrix data type is added. While PostgreSQL currently lacks indexing methods that support matrix data types, GIN indexes are known to be highly extensible, allowing custom data types to be implemented by designing appropriate access methods. Therefore, we will extend the matrix data type based on the extension methods provided by GIN indexes. We will implement input and output functions for this new data type and register it within the database.

[0067] 2. Create a new type of operator: Create an operator based on the database method, implement and register the functions required by various operators for the new data type.

[0068] 3. Define GIN access methods: The five main methods used here are compare, extractValue, extractQuery, consistent, and comparePartial. These methods define key values, relationships between key values, indexed values, queries that can use indexes, and partial matches.

[0069] Specifically, the compare method: compares two key values ​​a and b, and then returns an integer value. A negative value indicates that a<b,返回0表示a=b,返回正值表示a> b. Its function prototype is: int compare(Datum a, Datum b).

[0070] extractValue method: Generates a key-value array based on the parameter inputValue and returns its pointer. The number of elements in the key-value array is stored in another parameter nkeys. Its function prototype is Datum*extractValue(DatuminputValue, int32*nkeys).

[0071] extractQuery method: Generates a key-value array for query based on the query parameter and returns its pointer. Its function prototype is Datum*extractQuery(Datum query, int32*nkeys, StrategyNumber n, bool**pmatch, Pointer**extra_data).

[0072] consistent method: used to check whether the index value satisfies the query. Its function prototype is bool consistent(bool check[],StrategyNumber n,Datum query,int32 nkeys,Pointer extra_data[],bool*recheck).

[0073] The comparePartial method compares a partially matched query with the index value. A negative return value indicates a mismatch, but the index scan continues. A return value of 0 indicates a match. A positive return value stops the scan. Its prototype is (int comparePartial(Datum partial_key, Datum key, StrategyNumber n, Pointer extra_data)).

[0074] The above three steps implement GIN index support for matrix data types.

[0075] Because each node generates a large amount of data during system operation, storage space requirements are high. Furthermore, existing methods for querying the permissions of a matrix user require a large number of indexes and computational overhead, making it difficult to quickly determine which data the user has permission to operate on. Therefore, the above method constructs custom operators to extract and compare system data according to preset logic, resulting in a storage structure suitable for GIN indexing. Next, within the GIN framework, matrix data is imported by adding a matrix data type and constructing corresponding operators. Furthermore, by defining the five support functions required for GIN indexing, semantic parsing of the imported and stored matrix data is performed, thus enabling GIN index storage of matrix data.

[0076] According to one aspect of the present invention, a system for implementing a matrix user permission index on PostgreSQL is provided, comprising:

[0077] A matrix data model building module is used to build a matrix data model based on the system's organizational structure and the relationship between users and data. The matrix data model includes a user authority matrix and a data ownership matrix.

[0078] The data extraction module is used to extract the user authority matrix and the data attribution matrix row by row according to the preset extraction rules to obtain the user authority key and the data attribution unit;

[0079] The data comparison module is used to compare each user authority key with all data attribution units one by one according to the preset comparison rules, and obtain a list of each user authority key and the corresponding user data;

[0080] The data formation module is used to form a GIN index storage structure based on all user permission keys and the corresponding user data list;

[0081] The GIN extension module adds a matrix data type to PostgreSQL and builds operators corresponding to the matrix data type.

[0082] The index module defines the five support functions required for GIN indexes and implements indexing of the GIN index storage structure based on operators and support functions.

[0083] The constructed GIN index storage pair is stored according to the GIN index to implement the GIN index.

[0084] According to one aspect of the present invention, an electronic device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, at least one program, or the code set or instruction set is loaded and executed by the processor to implement the method for implementing an index of matrix user permissions on PostgreSQL as described in any one of claims 1 to 8.

[0085] Throughout this specification, reference to terms such as "one embodiment," "certain embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with the embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative descriptions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0086] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present invention.

Claims

1. A method for implementing matrix user rights indexing on PostgreSQL, characterized in that: This includes constructing operators to implement matrix data conversion and storing the converted matrix data based on GIN indexes. The construction of the operator to realize the conversion of matrix data further includes: According to the organizational structure of the system and the relationship between users and data, a matrix data model is established, wherein the matrix data model includes a user authority matrix and a data ownership matrix; According to the preset extraction rules, the user authority matrix and the data attribution matrix are extracted row by row to obtain the user authority key and the data attribution unit; For the user authority matrix, the extraction rule is: if the user has authority in a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the authority data of each row of the user authority matrix is ​​obtained; For the data attribution matrix, the extraction rule is: if a user generates data at a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the attribution data of each row of the data attribution matrix is ​​obtained; Each row of the matrix is ​​defined as ending with zero and represented by the letter Z. The extracted authority data and attribution data are processed to zero to obtain the simplified user authority key and data attribution unit. According to the preset comparison rules, each user authority key is compared with all data attribution units one by one to obtain a list of user authority keys and corresponding user data. The comparison rules include three: first, if a difference is found, it is false; second, when comparing the user authority key with the data attribution unit, if any one of them encounters the end character Z, the comparison is stopped and the result before the end is used as the final result; third, if a user authority key is compared with all data attribution units in a data attribution matrix and multiple results are obtained, the multiple results are in an OR relationship. A GIN index storage structure is formed based on all user permission keys and the corresponding user data list; The storage of the converted matrix data is implemented based on the GIN index, further including: Add a matrix data type to PostgreSQL and build operators corresponding to the matrix data type. Define these operators to handle relationships between matrix data. The internally handled relationship types include greater than, less than, and contained. The five support functions required to define a GIN index are compare, extractValue, extractQuery, consistent, and comparePartial. These support functions define key values, relationships between key values, indexed values, queries that can use the index, and partial matches. The GIN index storage structure is implemented based on these operators and support functions.

2. The method for implementing matrix user rights indexing on PostgreSQL according to claim 1, characterized in that: The system's organizational structure includes six levels of organizational nodes: school, site, teaching point, major, grade, and class. Each row of the user permission matrix corresponds to a piece of permission data for the user, and each column corresponds to an organizational node; each row of the data ownership matrix corresponds to the ownership of a piece of data, and each column corresponds to an organizational node.

3. The method for implementing matrix user rights indexing on PostgreSQL according to claim 2, characterized in that: The six-level organizational nodes of school, site, teaching point, major, grade, and class are abstractly represented as A, B, C, D, E, and F respectively. Each row in the user authority matrix and data attribution matrix is ​​represented as AaBbCcDdEeFf, where a represents the school number, b represents the site number, c represents the teaching point number, d represents the major number, e represents the grade number, and f represents the class number; and a matrix data model is constructed based on the user's authority at each organizational node and the data generated by the user at each organizational node.

4. The method for implementing matrix user rights indexing on PostgreSQL according to claim 1, characterized in that: Extract the user authority matrix and data attribution matrix row by row to obtain the user authority keys and data attribution units represented by rows. Perform pairwise comparisons between the user authority keys and data attribution units. If the comparison result is True, return True; otherwise, return False.

5. The method for implementing matrix user rights indexing on PostgreSQL according to claim 1, characterized in that: The GIN index storage structure is [Key, Postinglist], where Key represents the user permission key and Postinglist represents the user data list corresponding to the user permission key.

6. The matrix user rights index implementation system on PostgreSQL is characterized by: include: A matrix data model building module is used to build a matrix data model based on the system's organizational structure and the relationship between users and data. The matrix data model includes a user authority matrix and a data ownership matrix. The data extraction module is used to extract the user authority matrix and the data attribution matrix row by row according to the preset extraction rules to obtain the user authority key and the data attribution unit; wherein, For the user authority matrix, the extraction rule is: if the user has authority in a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the authority data of each row of the user authority matrix is ​​obtained; For the data attribution matrix, the extraction rule is: if a user generates data at a certain organization node, the corresponding organization node in the matrix is ​​extracted as the node number, and the subordinate nodes of the organization node are extracted as zero; after the extraction is completed, the attribution data of each row of the data attribution matrix is ​​obtained; The data extraction module is further configured to define each row of the matrix as ending with zero and representing it with the letter Z, and to perform zero processing on the extracted authority data and attribution data to obtain a simplified user authority key and data attribution unit; The data comparison module is used to compare each user authority key with all data attribution units one by one according to preset comparison rules, and obtain a list of user data corresponding to each user authority key. The comparison rules include three: first, if a difference is found in the comparison, it is false; second, when comparing the user authority key with the data attribution unit, if any of them encounters the end character Z, the comparison is stopped and the result before the end is used as the final result; third, if a user authority key is compared with all data attribution units in a data attribution matrix, there are multiple results, and the multiple results are in an OR relationship. The data formation module is used to form a GIN index storage structure based on all user permission keys and the corresponding user data list; The GIN extension module adds a matrix data type to PostgreSQL and builds operators corresponding to the matrix data type. It defines these operators to handle relationships between matrix data. The types of relationships handled internally include greater than, less than, and contained. The index module defines the five support functions required for GIN indexes: compare, extractValue, extractQuery, consistent, and comparePartial. These support functions define key values, relationships between key values, indexed values, queries that can use the index, and partial matches. The GIN index storage structure is indexed based on these operators and support functions.

7. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the indexing implementation method of matrix user permissions on PostgreSQL according to any one of claims 1 to 5.

Images