| 841 |
The expression of a check constraint that is associated with a domain needs type conversion |
Find check constraints of domains where the Boolean expression invokes an operation that does not match with the data type of the domain. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 842 |
The generator of surrogate key values can output the same value more than once |
Find surrogate keys where the generator can output the same value more than once. Key values must be unique, i.e., at some point the generator will prevent adding new rows to the table. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 843 |
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 |
2025-11-07 10:11 |
MIT License |
View |
| 844 |
The name of the routine does not match with the action of the routine |
Find user-defined non-trigger SQL and PL/pgSQL routines where the beginning of the name of the routine indicates a certain action inside the routine (INSERT, UPDATE, or DELETE) but there is no such statement in the routine body. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 845 |
The reference to a database operation is missing from a comment |
This query audits the metadata of user-defined routines to enforce traceability between the implementation and the design specifications. It identifies routines whose comments lack a standardized reference to the specific database operation contract they implement. The query checks for the absence of a required identifier pattern, typically formatted as OP followed by a number (e.g., OP1, OP12). Enforcing this standard ensures that every routine can be mapped back to its originating requirement or business rule. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-19 16:18 |
MIT License |
View |
| 846 |
There is no reason to use PL/pgSQL if you do not use one or more features of a procedural language |
Using PL/pgSQL may cause context switching between declarative SQL and procedural PL/pgSQL. Thus use PL/pgSQL only if you truly need some of its constructs (variables, conditional statements, cycles, cursors, exception handling). |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 847 |
There is no reason to use PL/pgSQL to write table functions |
Using PL/pgSQL may cause context switching between declarative SQL and procedural PL/pgSQL. Thus use PL/pgSQL only if you truly need some of its constructs. You can create table functions by using SQL. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 848 |
The same CHECK has a different name in different places |
Find the names of table CHECK constraints that have the same Boolean expression but a different naming style in different places (tables). The naming of constraints should be consistent. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code)x |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 849 |
The same CHECK has a different name in different places (2) |
This query audits the database schema to enforce a uniform naming strategy for CHECK constraints. It identifies inconsistencies where constraints enforcing identical Boolean expressions are named using disparate patterns across different tables. To isolate the naming pattern from specific object identifiers, the query normalizes the constraint names by substituting the actual table name with the generic token TABLE. This allows it to detect violations of the "Clean Code" principle of consistency—flagging cases where the same logical rule is implemented with a specific naming convention in one context (e.g., chk_TABLE_column) but a different convention in another (e.g., TABLE_column_check). |
Problem detection |
system catalog base tables only |
2025-11-27 10:17 |
MIT License |
View |
| 850 |
The same name is used in different contexsts |
Find the names that are used in case of different types of elements |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 851 |
The same sequence generator is used in case of multiple columns |
Do not cause a potential performance bottleneck by having a shared resource. By having a shared sequence it is not possible to change properties of sequences of different tables independently (for instance the owner column or step), i.e., it increases coupling between tables. By having a shared sequence it is impossible to specify the owner (table column) to the sequence generator. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 852 |
The SQL-language routines with the body that is string literal |
Find SQL-language routines that have the body that is string literal, i.e., the body is not SQL-standard function body. Routines with a SQL-standard body are permitted starting from PostgreSQL 14. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 853 |
Three-valued logic (Boolean columns) |
Find base table columns that have Boolean type and do not have NOT NULL constraint. Use two-valued logic (TRUE, FALSE) instead of three-valued logic (TRUE, FALSE, UNKNOWN). Because NULL in a Boolean column means unknown make all the Boolean columns mandatory. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 854 |
Three-valued logic (non-Boolean columns) |
Find non-foreign key columns of base tables that probably (based on the column name) contain values that represent truth values but do not have NOT NULL constraint. Use two-valued logic (TRUE, FALSE) instead of three-valued logic (TRUE, FALSE, UNKNOWN). Because NULL in a Boolean column means unknown make all the columns mandatory. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 855 |
Timezone-aware logic on timezone-unaware columns |
This query identifies logically flawed CHECK constraints on columns with timezone-unaware data types (DATE and TIMESTAMP WITHOUT TIME ZONE). It specifically targets constraints that contain timezone-aware logic (e.g., using AT TIME ZONE). This represents a critical semantic mismatch: the data type stores a "naive" or "local" time with no timezone context, while the constraint attempts to evaluate it within a specific timezone. The outcome of such a check is non-deterministic, as it depends on the session's current TimeZone setting, leading to unpredictable and unreliable data validation. This is a design flaw; if timezone-aware logic is required, the column should use the TIMESTAMP WITH TIME ZONE (TIMESTAMPTZ) data type. |
Problem detection |
system catalog base tables only |
2025-11-15 09:58 |
MIT License |
View |
| 856 |
Too few rounds in case of calculating the hash |
Find user-defined routines where gen_salt function is used with the number of rounds that is smaller than 12. The number should be adjusted based on the hardware where the system resides. Password hashing should take at least 250 ms. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 857 |
Too generic names (candidate key columns) |
Find candidate key columns with the names like id, identifikaator, code, kood, number, etc. The names should have a prefix or a suffix. These are too generic names. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 858 |
Too generic names (columns) |
This query audits the schema for semantically weak column identifiers. It identifies columns named with generic nouns (e.g., data, info, value) or context-free technical terms (e.g., id, type, code, date, fk, pk). Such names violate the principle of self-documenting schema design, as they fail to describe the specific domain attribute being stored. To prevent ambiguity—especially in complex joins—column names should carry sufficient semantic context (e.g., product_type instead of type, creation_date instead of date). |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 09:11 |
MIT License |
View |
| 859 |
Too generic names (columns) (aggregate view) |
This query generates a frequency distribution of semantically weak column identifiers within the schema. It aggregates the occurrences of generic names (e.g., id, type, data) to quantify their prevalence across the database. This statistical view serves as a prioritization tool for refactoring, highlighting the most ubiquitous violations of naming conventions that contribute to schema ambiguity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 09:15 |
MIT License |
View |
| 860 |
Too generic names (columns) (there is a column with a more specific name in the table) |
Find column names in case of which the same table has another column (with more specific name) that name contains the column name in the end or in the beginning. For instance, a base table has columns parent and root_parent and the former col-umn name is too generic, i.e., it should be more specific. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |