| 701 |
Some data modification functions return a value and some not |
Find as to whether there are data modification routines that return a value as well as data modification routines that do not return a value. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 702 |
Something is still to do in routines |
Find routines where comments contain TODO phrase. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 703 |
Sometimes current_timestamp, sometimes now() |
Find as to whether you sometimes use current_timestamp function and sometimes now() function. These implement the same functionality. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 704 |
Sometimes extract, sometimes date_part |
Find as to whether you sometimes use date_part function and sometimes extract function. These implement the same functionality. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 705 |
Sometimes regexp_like, sometimes ~ |
Find as to whether you sometimes use regexp_like function and sometimes ~ operator. These implement the same functionality. regexp_like function that was added to PostgreSQL 15 and provides the same functionality as ~ and ~* operators. Try to be consistent. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 706 |
Sorting rows based on random values in derived tables |
Find derived tables (views and materialized views) that sort rows based on random values. This can be used to find a random subset of rows. It is a computationally expensive operation. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 707 |
Sorting rows based on random values in derived tables without limiting rows |
Find derived tables (views and materialized views) that sort rows based on random values but do not limit the number of rows. This is unnecessary because without sorting the rows are returned in a unspecified order. Sorting based on random values is a computationally expensive operation. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 708 |
Sorting rows based on random values in routines |
Find routines that contain a statement that sorts rows based on random values. This can be used to find a random subset of rows. It is a computationally expensive operation. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 709 |
Sorting rows based on random values in routines without limiting rows |
Find routines that contain a statement that sorts rows based on random values but do not limit the number of rows. This is unnecessary because without sorting the rows are returned in a unspecified order. Sorting based on random values is a computationally expensive operation. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 710 |
SQL function does not return a value |
Find SQL functions that do not return a value (return VOID) but the SQL statement in the function has RETURNING clause. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 711 |
STATEMENT level triggers and ROW level AFTER triggers without RETURN NULL |
Write correct code "The return value of a row-level trigger fired AFTER or a statement-level trigger fired BEFORE or AFTER is always ignored; it might as well be null." (PostgreSQL documentation) |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 712 |
STATEMENT level triggers that refer to the values of row variables NEW or OLD |
Find STATEMENT level triggers that refer to the values of row variables NEW or OLD. NEW and OLD are special variables that can only be used in row-level trigger procedures. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 713 |
Stating the obvious |
Find database objects that name contains words "data" or "info". These are noise words because databases are meant for storing and manipulating data/information. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 714 |
Stating the obvious (2) |
Find the names of database objects where the name of the database object contains a part of the name of the object type. For instance, the query finds base tables, were the name contains fragments _base, base_, _table, or table_. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 715 |
Subqueries of derived tables with LIMIT/FETCH/DISTINCT ON without ORDER BY |
Find subqueries of derived tables (views, materialized views) with the LIMIT/FETCH clause or with DISTINCT ON construct but without the ORDER BY clause. These constructs require sorting to produce a meaningful result. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 716 |
Superfluous IS NULL checks in constraints |
This query identifies CHECK constraints that contain redundant logic for handling NULLs, a pattern often arising from a misunderstanding of SQL's three-valued logic (TRUE, FALSE, UNKNOWN). A CHECK constraint's condition only fails on FALSE, implicitly permitting NULLs by evaluating comparisons to UNKNOWN. Consequently, an explicit OR column IS NULL clause is tautological and adds no functional value, as demonstrated by the equivalence of CHECK (price IS NULL OR price > 0) and CHECK (price > 0). Removing this superfluous logic improves constraint clarity and eliminates a marginal but unnecessary computational step. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-15 10:19 |
MIT License |
View |
| 717 |
Surrogate key columns |
Find surrogate keys. Surrogate key is a key that consist of one column, which has an integer type. The key has been declared by using PRIMARY KEY or UNIQUE constraint. The column is associated with a sequence generator (either external or internal, i.e., created by the system automatically because the column has been declared as an identity column). The column does not participate in any foreign key. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 718 |
Surrogate key columns that do not follow the naming style |
Find surrogate key columns that name does not end with "id_" or start with "id_". |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 719 |
Surrogate keys in classifier tables |
This query identifies potential classifier (or reference) tables that contain a column populated by a sequence generator. In good database design, tables storing standard reference data should typically use natural keys rather than auto-incrementing surrogate keys. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-05-29 15:49 |
MIT License |
View |
| 720 |
Surrogate keys using non-standard SERIAL pseudo-type |
This query identifies surrogate key columns defined using the legacy, PostgreSQL-specific SERIAL (or BIGSERIAL) pseudo-type. While functional, this notation is not part of the ISO SQL standard. The recommended best practice in modern PostgreSQL versions is to utilize GENERATED AS IDENTITY columns. Identity columns are standard-compliant and offer superior management of underlying sequences and permissions compared to the older SERIAL implementation. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-24 20:43 |
MIT License |
View |