| Seq nr | Name | Goal▲ | Type | Data source | Last update | License | ... |
|---|---|---|---|---|---|---|---|
| 861 | Names of database objects that are used to manage the state of main objects in the database | "Names in software are 90 percent of what make software readable. You need to take the time to choose them wisely and keep them relevant. Names are too important to treat carelessly. Names should not cause confusion." (Robert C. Martin, Clean Code) The naming must be consistent. One should avoid mixing synonyms like "seisund", "staatus", and "olek" in Estonian or "state" and "status" in English and stick with one term. | General | INFORMATION_SCHEMA+system catalog base tables | 2023-03-18 16:53 | MIT License | |
| 862 | Inconsistent names of database objects that are used to manage the state of main objects in the database | "Names in software are 90 percent of what make software readable. You need to take the time to choose them wisely and keep them relevant. Names are too important to treat carelessly. Names should not cause confusion." (Robert C. Martin, Clean Code) The naming must be consistent. One should avoid mixing synonyms like "seisund", "staatus", and "olek" in Estonian or "state" and "status" in English and stick with one term. For instance, it is a bad practice to use word "state" in table names but word "status" in function names. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-03-18 17:13 | MIT License | |
| 863 | Names of database objects with perhaps too many subcomponents (terms) | "Names in software are 90 percent of what make software readable. You need to take the time to choose them wisely and keep them relevant. Names are too important to treat carelessly. Names should not cause confusion." (Robert C. Martin, Clean Code) The number of subcomponents (terms) should not be too big. Find the names (identifiers) of user-defined database objects that perhaps contain too many subcomponents, assuming, that the separator of the components is "_". | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-03-17 10:02 | MIT License | |
| 864 | The number and percentage of different names of database objects | Names should be expressive. Find the number of different names used in a database as well as the number of named database objects, and the percentage of different names from all the names. Names should be expressive. Different objects should have different names. The smaller the percentage the less descriptive are the names in the database. Find the number of different names (identifiers) of user-defined database objects and compare it with the total number of database objects. The values could be used to compare different databases. | Sofware measure | INFORMATION_SCHEMA+system catalog base tables | 2023-03-18 17:12 | MIT License | |
| 865 | Too short view names | Names should be expressive. Find views that name is shorter than the average length of the the names of its directly underlying tables (both base tables and derived tables). | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 866 | 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 | 2021-02-25 17:30 | MIT License | |
| 867 | Perhaps too many different prefixes in the names of database objects that have the same type | One should be consistent in naming, including in the use of prefixes. If you use prefix in the name of a database object, then it should refer to the type of the database object. Do not use different prefixes in the names of database objects that have the same type. Find types of database objects in case of which there are different prefixes in different names. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-03-18 17:16 | MIT License | |
| 868 | Perhaps too many different suffixes in the names of database objects that have the same type | One should be consistent in naming, including in the use of suffixes. If you use sufix in the name of a database object, then it should refer to the type of the database object. Do not use different suffixes in the names of database objects that have the same type. Find types of database objects in case of which there are different suffixes in different names. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-03-17 11:14 | MIT License | |
| 869 | The maximum number of characters may be missing | Perhaps the character maximum length has been omitted accidentally, i.e., one wrote VARCHAR instead of VARCHAR(n) where n is the maximum permitted number of characters in the field value. VARCHAR and TEXT are synonyms. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 870 | Numeric literals between apostrophes | Placing numeric literals between apostrophes will cause unnecessary type conversions. It could also be that the literal should indeed be textual but the problem is in choosing the values. For instance, table Occupation has column occupation_code with the type VARCHAR(3). However, all the values in the column consist of digits (for instance, 1, 2, 3). Thus, it would have been better to a) use SMALLINT as the column type or b) use different occupation codes that contain additional symbols to digits. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-04 13:20 | MIT License | |
| 871 | Unnecessary usage privileges of PUBLIC | PostgreSQL gives by default some privileges to all the present and future database users (PUBLIC). Find usage privileges of collations, domains, foreign data wrappers, foreign servers, and sequences that have been given to PUBLIC. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-12-31 13:53 | MIT License | |
| 872 | Invalid character class | PostgreSQL regular expressions do not have character classes word and letter. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-04 12:50 | MIT License | |
| 873 | Explicit locking | PostgreSQL uses Multi-version Concurrency Control (MVCC) and thus, sometimes, one has to explicitly lock certain rows or entire table. One has to use LOCK TABLE or SELECT … FOR UPDATE statements for that. | General | INFORMATION_SCHEMA+system catalog base tables | 2023-12-11 15:02 | MIT License | |
| 874 | Explicit locking is missing | PostgreSQL uses multiversion concurrency control (MVCC). SELECTs do not block modifications and vice versa. One has to take steps to achieve correct behaviour. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-01-14 00:35 | MIT License | |
| 875 | Foreign keys with ON UPDATE CASCADE | Referential constraints (foreign key constraints) that employ ON UPDATE CASCADE compensatory action. ON UPDATE CASCADE should only be used if the referenced key is a natural key (its values can be changed). | General | system catalog base tables only | 2020-11-15 15:39 | MIT License | |
| 876 | Referential degree of a schema | Referential degree of a schema is defined as the number of foreign keys in the database schema. | Sofware measure | INFORMATION_SCHEMA only | 2020-11-13 11:30 | MIT License | |
| 877 | Case insensitive search | Refers to the column pg_proc.prokind and thus works starting from PostgreSQL 11. Find user-defined routines and derived tables (views/materialized views) that have a subquery with case insensitive search (by using the upper or lower function or ILIKE predicate or (?i) modifier of a regular expression pattern). | General | INFORMATION_SCHEMA+system catalog base tables | 2021-10-25 16:55 | MIT License | |
| 878 | Overloading may cause runtime error | Routines in the same schema that have the same name and that have parameters with different types or different number of parameters are not considered to be in conflict at the creation time. However, if defaults are provided in the definition of parameters, then these routines might be conflict during runtime. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-10-25 16:11 | MIT License | |
| 879 | Unsecure SECURITY DEFINER routines | SECURITY DEFINER routines must be secured against the malicious use of pg_temp schema. Find routines that do not explicitly set the search path or do it incorrectly (the search path is between quotation marks) and are thus potential targets of the attack. pg_temp must be the last entry in search_path. The lack of search_path is allowed only if the SQL statements in routines explicitly refer to the schemas that contain the schema objects. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-11-13 12:07 | MIT License | |
| 880 | SELECT * in a routine body | SELECT statement should list the columns not use SELECT * to return data from all the columns. Firstly, it ensures, that the query asks only data that is really needed by the routine. It means less data that the DBMS has to fetch and pass to the routine. It could also mean that the DBMS can answer to a query based on an index without reading table blocks. Secondly, it documents the data that is returned by the query. The query does not consider objects that are a part of an extension. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-04 15:03 | MIT License |