| # | Name | Goal | Type | Data source ▲ | Last update | License | |
|---|---|---|---|---|---|---|---|
| 361 | Duplication of case insensitivity specification in a regular expression | Find regular expressions that use both case insensitive search operator ~* and case insensitivity modifier (?i). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 362 | Duplication of parent table CHECK constraints on the foreign key columns | Find duplicate constraints, which make it more difficult to maintain the constraints. Do remember that the same task can be solved in SQL usually in multiple different ways. Thus, the exact copies are not the only possible duplication. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 363 | Duplication of simple CHECK constraints on the same column | Find duplication of simple CHECK constraints on the same base table or foreign table column. Duplication of the same constraint means that if one starts to manage the code, then changes have to be made in multiple places. The problem is essentially similar with the data redundancy problem that database normalization tries to reduce. Do remember that the same task can be solved in SQL usually in multiple different ways. Thus, the exact copies are not the only possible duplication. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 364 | Each table is both referencing and referenced table (perhaps there is a cycle in relationships) | Find as to whether the relationships between tables form a complete bidirected graph. Tables are vertices in the graph. There is a directed edge between two vertices if one of the tables refers to another through foreign key relationship on mandatory columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 365 | Empty columns | Find columns in non-empty tables that do not contain any values. If there are no values in a columns, then it may mean that one hasn't tested constraints that have been declared to the column or implemented by using triggers. It could also mean that such columns are not needed at all. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 366 | Empty schemas | This query identifies empty schemas within the database. A schema is considered empty if it exists as a namespace but contains no database objects, such as tables, views, functions, or types. The presence of such schemas often indicates artifacts from failed or incomplete migrations, obsolete application components, or setup errors, and they can be safely removed to reduce schema clutter. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-13 14:15 | MIT License | View |
| 367 | Enumerated or range types with the same name in different schemas | This query enforces the Don't Repeat Yorself principle across the database's type system. It identifies ENUM and RANGE types that share the same name but exist in different schemas. This indicates that a conceptual data type has been defined multiple times instead of having a single, canonical definition in a shared schema. Such duplication leads to maintenance overhead and the risk of semantic divergence over time. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 12:38 | MIT License | View |
| 368 | Enumerated types with zero or one value | Fidn enumerated types with zero or one value. Type is a named finite set of values. The empty set is a set. A set with one value is a set. Thus, types with zero or one value are legal. In practical terms each type, usually, should contain at least two values. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 369 | Excessive locking with FOR UPDATE in subqueries | This query identifies performance and concurrency bottlenecks caused by excessive locking. It flags INSERT, UPDATE, or DELETE statements that utilize subqueries containing the FOR UPDATE clause. Using FOR UPDATE acquires an exclusive lock, which is semantically inappropriate if the rows in the subquery are merely being read for reference or validation rather than being modified. This practice degrades system concurrency by unnecessarily blocking other transactions. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 11:26 | MIT License | View |
| 370 | Exclude constraint to prevent overlapping time periods | Find exclude constraints on base tables with multiple date/timestamp columns that prevent overlapping time periods. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 371 | Explicit locking | This query identifies user-defined routines that employ explicit locking mechanisms to supplement PostgreSQL's default Multi-Version Concurrency Control (MVCC). It detects the presence of table-level locking (LOCK TABLE) or explicit row-level locking clauses (e.g., SELECT ... FOR UPDATE, FOR SHARE). While MVCC generally provides sufficient isolation for concurrent transactions, explicit locking is necessary in specific race-condition scenarios. This inventory assists in auditing concurrency control strategies and detecting potential sources of deadlocks or serialization bottlenecks. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-12-10 13:13 | MIT License | View |
| 372 | Explicit locking is missing | This query identifies concurrency risks in user-defined routines by flagging INSERT, UPDATE, or DELETE statements that utilize subqueries without a FOR SHARE locking clause. Failure to acquire a shared lock on source rows allows concurrent transactions to modify or delete them between the subquery's execution and the outer operation, potentially leading to data inconsistencies. Routines utilizing the xmin system column are excluded, operating on the assumption that they implement Optimistic Concurrency Control (version checking) and therefore do not require pessimistic locking. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 12:45 | MIT License | View |
| 373 | Explicit locking is missing (2) (ChatGPT version) | This query identifies concurrency risks in user-defined routines by flagging INSERT, UPDATE, or DELETE statements that utilize subqueries without a FOR SHARE locking clause. Failure to acquire a shared lock on source rows allows concurrent transactions to modify or delete them between the subquery's execution and the outer operation, potentially leading to data inconsistencies. Routines utilizing the xmin system column are excluded, operating on the assumption that they implement Optimistic Concurrency Control (version checking) and therefore do not require pessimistic locking. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 12:41 | MIT License | View |
| 374 | Extension routines that execution privilege has been granted to PUBLIC | Know the privileges that users have in your system. Probably all the database users do not need these privileges. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 375 | Extreme contraction | Find names that contain extremely short terms, due to an excessive word contraction, abbreviation, or acronym usage. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 376 | FILLFACTOR is probably too big | This query identifies base tables with a potentially suboptimal FILLFACTOR setting, targeting those that likely undergo UPDATE operations. A high FILLFACTOR on such tables can lead to poor performance by reducing the likelihood of Heap-Only Tuple (HOT) updates. When a new row version cannot be stored on the same page as the old version, all indexes on the table must be updated with the new tuple's location. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:08 | MIT License | View |
| 377 | FILLFACTOR is probably too small | This query identifies base tables with a FILLFACTOR setting below 90, flagging them for potentially inefficient storage utilization. While a low FILLFACTOR is intended to accommodate UPDATEs, an excessively low value can lead to wasted disk space and reduced data density, negatively impacting the performance of operations like full table scans. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:10 | MIT License | View |
| 378 | FILLFACTOR is probably too small (2) | This query identifies base tables with a suboptimal FILLFACTOR setting, specifically targeting tables that are heuristically identified as junction tables in a many-to-many relationship. A table is considered a probable junction table if it primarily consists of foreign and primary key columns, with no additional data columns that would suggest UPDATE operations. For these tables, the workload is almost exclusively INSERT and DELETE. Therefore, a FILLFACTOR below 100 serves no performance benefit and results only in wasted storage space and reduced data density. The job of these linking tables is simple: you add a line to connect two things, or you remove the line to disconnect them. You almost never change a line that's already there. The fillfactor setting is used to leave empty space for changes. |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:13 | MIT License | View |
| 379 | Find all non-foreign key columns of base tables | Find all non-foreign key columns of base tables. Make sure that no foreign key constraint is missing. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 380 | Find all publications | Find publications of tables that have been created in order to enable logical replication. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |