| 761 |
Routine body only in uppercase |
Uppercase means screaming and having code entirely in uppercase makes its reading more difficult. On the other hand, it would be a good idea to have keywords in uppercase. Find routines that body contains a SQL data manipulation statement (which shouldn't be entirely in uppercase) but still the body is completely in uppercase. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 762 |
Routine body with ordering the query result based on positional references |
Find routines where the query result is sorted based on the column number in the SELECT clause. Such query is sensitive towards changing the order of columns in the SELECT clause, i.e., if one changes the order of columns in the SELECT clause, then one must change the numbers in the ORDER BY clause as well, otherwise the query will produce undesired order of rows. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 763 |
Routine for reading data uses another routine to read some data |
This query analyzes the call graph of user-defined routines to identify nested data retrieval patterns. It flags routines that are operationally read-only (performing no DML) but rely on invoking other routines to access additional data. This indicates a layered architecture where data access logic is encapsulated and chained. Identifying these routines is essential for performance profiling, as the total cost of execution is distributed across the call stack rather than being contained within a single procedure body. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-26 11:48 |
MIT License |
View |
| 764 |
Routines lacking explicit locking (MVCC risks) |
This query identifies user-defined routines that may be susceptible to concurrency anomalies due to a lack of explicit locking. PostgreSQL utilizes Multi-Version Concurrency Control (MVCC), where SELECT statements do not block data modification operations. Consequently, routines that read data to inform subsequent modifications without acquiring row-level locks (e.g., FOR UPDATE, FOR SHARE) or using isolation levels higher than READ COMMITTED are prone to race conditions. This query flags such routines for review to ensure transactional integrity is maintained. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-14 14:44 |
MIT License |
View |
| 765 |
Routines that can be invoked with a variable number of arguments |
Find routines with a VARIADIC parameter. These are routines that take as input an undefined number of arguments where the argument that is an undefined number are all of the same type and are the last input arguments. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 766 |
Routines that use old syntax for limiting rows |
This query identifies PL/pgSQL and SQL routines with no SQL-standard bodies that use the non-standard LIMIT clause for row limitation. It flags these routines because the official, cross-platform SQL standard specifies FETCH FIRST n ROWS ONLY for this purpose. Adhering to the standard improves code portability and maintainability. To ensure relevance, the query intelligently excludes routines that are part of installed extensions, focusing only on user-defined code. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-21 17:37 |
MIT License |
View |
| 767 |
Routines with BOOLEAN return type that do not have a good name |
This query audits the naming conventions of routines that return a BOOLEAN data type. It identifies routines that do not adhere to the recommended semantic prefix convention (i.e., starting with is_, has_, can_, or on_). A function name should represent a state or a question (e.g., has_rights) rather than an action (e.g., check_rights). Enforcing this standard makes the routine's purpose and return value immediately obvious from its name. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 13:53 |
MIT License |
View |
| 768 |
Routines with INSERT statements that are sensitive towards the order of columns |
INSERT statements shouldn't be sensitive towards the order of columns. If one changes the order of columns in a table then these statements must be rewritten. Otherwise the code will not work or works incorrectly. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 769 |
Routines with non-deterministic side effects and static return values |
This query identifies SQL routines that exhibit a dangerous combination of state-changing side effects (DML) and a static return value (either a constant literal or an unmodified input parameter). The function's name and signature often imply that the return value is the result of its operations (e.g., a new balance, a generated ID). However, the static return value contradicts this, creating a semantic disconnect between the routine's name and its contract. This is a significant design flaw that can lead to subtle but critical bugs, as the calling code may act on a return value that does not accurately reflect the database state after the routine's execution. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-15 10:59 |
MIT License |
View |
| 770 |
Routines without an action |
Find routines that body does not contain any action. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 771 |
Routines with the same name and parameters in different schemas |
Find user-defined routines with the same name and parameters (including the order of parameters) in different schemas. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 772 |
Routines with type casting |
Make sure that your parameters have appropriate types in order to avoid unnecessary type casting. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 773 |
ROW level BEFORE DELETE and INSTEAD OF DELETE triggers that procedures refer to the row variable NEW |
Do not write incorrect code. Variable NEW: "Data type RECORD; variable holding the new database row for INSERT/UPDATE operations in row-level triggers. This variable is null in statement-level triggers and for DELETE operations." (PostgreSQL documentation) |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 774 |
ROW level BEFORE INSERT and INSTEAD OF INSERT triggers that procedures refer to the row variable OLD |
Do not write incorrect code. Variable OLD: "Data type RECORD; variable holding the old database row for UPDATE/DELETE operations in row-level triggers. This variable is null in statement-level triggers and for INSERT operations." (PostgreSQL documentation) |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 775 |
Row-level BEFORE triggers on base tables with RETURN NULL cancellation logic |
This query identifies row-level BEFORE triggers on base tables that execute a RETURN NULL statement without raising a corresponding exception. In PostgreSQL, returning NULL from a BEFORE trigger silently aborts the pending INSERT, UPDATE, or DELETE operation for the current row. Unlike an exception, which alerts the calling application to the failure, a silent cancellation allows the transaction to proceed as if successful, but with the data modification discarded. This behavior is often unintentional (e.g., a forgotten RETURN NEW) and poses a significant risk of data loss and difficult-to-debug application logic errors. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-20 12:29 |
MIT License |
View |
| 776 |
ROW level BEFORE triggers that do not return a row if a check succeeds |
Find ROW level BEFORE triggers that check a condition based on other rows, raise an exception but do not return the row if the condition check succeeds, i.e., exception is not raised. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 777 |
ROW level BEFORE triggers with RAISE EXCEPTION but without RETURN NULL |
Although RAISE EXCEPTION stops the execution it would be a good style to still return. In this case the return should bring back NULL, i.e., the row will not be processed further |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 778 |
ROW level BEFORE UPDATE triggers that do not return the new row |
Find row level BEFORE UPDATE triggers that do not return the new row version. Exclude triggers that raise WARNING/EXCEPTION. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 779 |
Row level triggers that update or delete data |
This query identifies row-level triggers that contain UPDATE or DELETE statements within their execution body. Embedding data modification logic directly within row-level triggers introduces implicit side effects that can complicate transaction management and debugging. Furthermore, this pattern significantly increases the risk of causing cascading trigger chains or infinite recursion loops, potentially degrading system performance and stability. Such logic should be carefully audited to ensure it is strictly necessary and correctly implemented. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-14 12:20 |
MIT License |
View |
| 780 |
Row-level triggers with RETURN NULL cancellation logic |
This query identifies row-level BEFORE and INSTEAD OF triggers that explicitly RETURN NULL. In PostgreSQL's trigger execution model, this return value acts as a cancellation signal. For BEFORE triggers on tables, it aborts the operation for the current row, preventing the INSERT, UPDATE, or DELETE and suppressing subsequent triggers. For INSTEAD OF triggers on views, it signals that no modification was performed. While this behavior can be used for conditional logic (e.g., silently ignoring invalid rows), it presents a risk of unintended data loss or logic errors if used incorrectly. These triggers should be audited to ensure the cancellation behavior is intentional and correctly implemented. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-20 11:41 |
MIT License |
View |