| # | Name ▲ | Goal | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 381 | Grantable usage privileges | Find usage privileges that the carrier of the privilege can in turn grant to others, i.e., the privileges have been given WITH GRANT OPTION. The number of privileges that can be passed on should be as small as possible. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 382 | Granted roles | Find membership relations between roles. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 383 | Grantees | Database must be used by users who have minimal set of privileges for performing tasks. The query helps to find out as to whether some user/role other than PUBLIC and a superuser have rights to use tables and routines of the database. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 384 | Gratuitous context in the names of foreign key columns | Find foreign key columns that name contains twice the name of the referenced (primary) table. | Problem detection | system catalog base tables only | 2025-11-07 10:12 | MIT License | View |
| 385 | Gratuitous context in the names of non-foreign key and non-primary key columns | This query identifies base table columns that unnecessarily include the table name. It searches for columns that are not part of a primary or foreign key and contain the name of their parent table. To avoid flagging legitimate naming conventions, it explicitly excludes a list of generic column names (e.g., name, description, nimi, kommentaar) where prefixing with the table name is considered good practice for improving clarity in queries. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:12 | MIT License | View |
| 386 | Gratuitous context in the names of parameters | This query enforces a concise coding style by checking the names of parameters within routines (such as functions or procedures). It finds parameters whose names unnecessarily repeat the name of the routine they belong to. For example, in a function named calculate_invoice, a parameter named calculate_invoice_id would be flagged, as invoice_id is sufficient. A routine cannot have two parameters with the same name, so the shorter name is unambiguous within the context of the routine and results in cleaner, more readable code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:12 | MIT License | View |
| 387 | Gratuitous context in the names of schema objects | This query identifies schema objects with names that are redundantly prefixed with their own schema's name. It flags any object whose name begins with the schema name plus at least one other character. This enforces the design principle that a schema is a sufficient namespace, and therefore, objects within it do not require the additional, repetitive context in their own names. | Problem detection | system catalog base tables only | 2025-11-07 10:12 | MIT License | View |
| 388 | Identical indexes | Find indexes that are identical, i.e., have the same properties, including uniqueness. The query considers all types of indexes, including indexes that have been automatically created to support a constraint and function-based indexes. | Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 389 | Identifiers that explicitly say that they carry no meaning | Find identifiers that explicitly say that they carry no meaning. Such identifier is called "unnamed" or "anonymous". | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 390 | Inappropriate field size or data type for column that strores database username | Find columns of base tables that based on the default value of the column contain database username. However, the type of the column is not VARCHAR(63) or VARCHAR(128). | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 391 | Inappropriate use of trim function in whitespace constraints | This query identifies a semantic mismatch between the name and implementation of CHECK constraints (on tables, foreign tables, or domains). It targets constraints whose names suggest they validate against whitespace-only strings (e.g., names containing 'whitespace', 'space', 'blank'), but whose logic inappropriately uses the trim() function. The trim() function is a formatting tool for removing leading/trailing spaces, not a validation tool for ensuring a string is not composed entirely of whitespace. This indicates a likely implementation error, as a more robust regular expression (e.g., column !~ '^\s*$') is the correct tool for this type of validation. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 12:34 | MIT License | View |
| 392 | Inconsistency between the name and the type of a base table column (dates) | Find base table columns that name refers to the possibility that these are used to register dates. Find the columns that do not have an appropriate data type. Column names should reflect the data that is possible to record in the column. For instance, in case of temporal data the column name should indicate as to whether we record dates or timestamps. If the column data type is "date", then the suffix of the column name should be "kp" (Estonian) or "date" (English). | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 393 | Inconsistency between the name and the type of a base table column (timestamps) | Find base table columns that name refers to the possibility that these are used to register timestamps. Find the columns that do not have an appropriate data type. Column names should reflect the data that is possible to record in the column. For instance, in case of temporal data the column name should indicate as to whether we record dates or timestamps. If the column type is "timestamp", then the suffix of the column name should be "aeg" (Estonian) or "time" (English). | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 394 | Inconsistency between the type and the default value of a column (date and timestamp values) | Find table columns with timestamp/date types that data type and dynamically found default value have a different type. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 395 | Inconsistency between the type and the default value of a column (time values) | Find table columns with time types, which data type and dynamically found default value have a different type. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 396 | Inconsistency (code vs. id) of naming foreign key and referenced candidate key columns | Naming of foreign key and referenced candidate key columns should be consistent. It cannot be so that in one table a value is labeled "id" like some surrogate key value and in another it "turns" into human-usable "code" or vice versa. An example: Person(person_id, name) Primary Key (person_id) E_mail_address(e_mail_address_id, person_code, address) Primary Key (e_mail_address_id) Foreign key (person_code) References Person (person_id) |
Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 397 | Inconsistency of using column data types/field sizes in case of columns that implement relationships | Find foreign key constraints where the candidate key columns (belong to a PRIMARY KEY/UNIQUE constraint) and foreign key columns do not have the same data type and field size. Primary key/unique columns and foreign key columns should have the same data type and field size. If, for instance, the primary key column has type INTEGER and foreign key column has type SMALLINT, then one cannot use all the primary key values as foreign key values. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 398 | Inconsistency of using parameter data types | Find parameters of routines that have the same name but a different type. Parameters that have the same name should have, in general, the same data type as well, assuming that the routines, which have the parameters, have different names, i.e., there is no overloading in play. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 399 | Inconsistent chain of relationships in terms of using ON UPDATE compensating action | In case of a chain of relationships between tables (where the primary key and the foreign key have the same columns) the use of ON UPDATE compensating action should be consistent. For instance, in the next example there is inconsistency, because if one changes the person_code in table Person, then the modification does not succeed because it does not cascade to the table Product. It is unclear as to whether it should be possible to change the person_code or not. Person (person_code, surname) Primary key (person_code) Worker(person_code) Primary key (person_code) Foreign key (person_code) References Person (person_code) ON UPDATE CASCADE Product(product_code, registrator) Primary key (product_code) Foreign key (registrator) References Worker (person_code) ON UPDATE NO ACTION |
Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 400 | Inconsistent CHECK constraints on columns with the same name | This query identifies inconsistencies in data validation for columns that share the same name across different tables. It flags cases where a conceptual data element (e.g., 'email', 'postal_code') is subject to a CHECK constraint in some tables but lacks one in others. This violates the principle of uniform data integrity, creates semantic ambiguity, and can allow invalid data to enter the system through the unconstrained columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 09:53 | MIT License | View |