| 821 |
Using BEFORE triggers to log data changes |
Do not let the system to do extra work. Logging changes with a BEFORE trigger means extra work for rolling back the changes in case the logged data modification fails. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 822 |
Using conditionals to determine the returned value |
Use SQL language instead of PL/pgSQL where possible. Instead of using an IF statement, you can check as to whether the data modification succeeded or not by using the RETURNING clause in the data modification statement. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 823 |
Using in some way reserved (in PostgreSQL) SQL keywords as the names of a database object (aggregate view) |
"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) Names should not cause confusion. Find the distinct names (identifiers) of user-defined objects that are SQL keywords that are not completely unreserved in PostgreSQL, i.e., these either never cannot be used as regular identifiers or cannot be used in case of some type of database objects. In PostgreSQL "there are several different classes of tokens ranging from those that can never be used as an identifier to those that have absolutely no special status in the parser as compared to an ordinary identifier. " (PostgreSQL manual) Moreover, such identifiers are often too general, i.e., do not provide enough information about the named object. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 824 |
Using in some way reserved (in PostgreSQL) SQL keywords as the names of a database object (detailed view) |
"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) Names should not cause confusion. Find the names (identifiers) of user-defined objects that are SQL keywords that are not completely unreserved in PostgreSQL, i.e., these either never cannot be used as regular identifiers or cannot be used in case of some type of database objects. In PostgreSQL "there are several different classes of tokens ranging from those that can never be used as an identifier to those that have absolutely no special status in the parser as compared to an ordinary identifier. " (PostgreSQL manual) Moreover, such identifiers are often too general, i.e., do not provide enough information about the named object. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 825 |
Using routine name in front of a parameter name in a routine body to refer to the parameter of the routine |
Write code that is easy to understand and not unnecessarily long. A routine cannot have two or more parameters with the same name. In this case using longer identifier in the form routine_name.parameter name is unnecessary. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 826 |
Using unreserved (in PostgreSQL) SQL keywords as the names of a database object (aggregate view) |
"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) Names should not cause confusion. Find the distinct names (identifiers) of user-defined objects that are SQL keywords that are completely unreserved in PostgreSQL. In PostgreSQL "there are several different classes of tokens ranging from those that can never be used as an identifier to those that have absolutely no special status in the parser as compared to an ordinary identifier. " (PostgreSQL manual) Although the names are unreserved keywords in PostgreSQL these could be reserved keywords in other systems, which would complicate database migration. Moreover, such identifiers are often too general, i.e., do not provide enough information about the named object. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 827 |
Using unreserved (in PostgreSQL) SQL keywords as the names of a database object (detailed view) |
"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) Names should not cause confusion. Find the names (identifiers) of user-defined objects that are SQL keywords that are completely unreserved in PostgreSQL. In PostgreSQL "there are several different classes of tokens ranging from those that can never be used as an identifier to those that have absolutely no special status in the parser as compared to an ordinary identifier. " (PostgreSQL manual) Although the names are unreserved keywords in PostgreSQL these could be reserved keywords in other systems, which would complicate database migration. Moreover, such identifiers are often too general, i.e., do not provide enough information about the named object. Think as to whether some better name would be possible. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 828 |
Validation method does not confirm |
Find user-defined SQL and PL/pgSQL routines that do not return a value although the name suggest that it should return a value (starts with "validate" or "check"). |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 829 |
Very similar (but not equal) routine names |
This query audits the schema for semantic ambiguity by identifying pairs of routine names (functions, procedures) that exhibit high textual similarity but are not identical. It filters for name pairs with a Levenshtein edit distance of exactly one (less than two, but excluding equality). This specific filter targets typographical errors (e.g., calc_tax vs. calc_tux) or inconsistent singular/plural naming (e.g., get_user vs. get_users), while correctly ignoring valid method overloading where names are identical. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-25 17:29 |
MIT License |
View |
| 830 |
Very similar column names |
This query performs an intra-table analysis to detect potential schema ambiguities. It identifies pairs of columns within the same table that exhibit both high textual similarity and structural equivalence. Specifically, it flags pairs where the names have a Levenshtein edit distance of exactly one and the columns share the same data type or domain. This combination suggests a high probability of typographical errors (e.g., status vs statuss), inconsistent naming (singular vs. plural), or improper denormalization (e.g., item1 vs item2), all of which undermine schema clarity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-25 17:32 |
MIT License |
View |
| 831 |
Very similar table names |
This query identifies potential redundancy or ambiguity in the schema by detecting pairs of table names with high textual similarity. It utilizes the Levenshtein distance algorithm to find name pairs that differ by fewer than two characters (i.e., a distance of 0 or 1). This check applies across different types of tables (base tables, foreign tables, derived tables), helping to uncover typographical errors (e.g., users vs user), inconsistent pluralization, or confusingly named entities that violate the principle of distinct and descriptive identifiers. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-25 17:24 |
MIT License |
View |
| 832 |
Views without security barrier |
Find views that do not have the security barrier option. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 833 |
Views with unnecessary security invoker |
Find views with security invoker option that do not have any underlying base table with a security policy. Security invoker option of views is possible starting from PostgreSQL 15. "The main use case (and the one that inspired the feature) is to be able to use views and still check row-level security policies on the underlying tables as the invoker." |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 834 |
Views with WHERE but without security barrier |
Find views that do not have the security barrier option but restrict rows in some way. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 835 |
YELLING IN COMMENTS! |
Find comments of derived tables and routines that consist of only uppercase letters. Do not use only uppercase (capital) letters in order to write comments. It means yelling and also makes text less readable. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 836 |
All clustered indexes |
Find all tables that rows have been physically sorted based on an index. |
General |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 837 |
All database privileges |
Find the privileges to use the database. c - CONNECT; C - CREATE; T - TEMPORARY. |
General |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 838 |
All event triggers |
Find event triggers, which are not associated to a specific schema object. |
General |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 839 |
All exclude constraints |
Find all exclude constraints. |
General |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 840 |
All foreign key constraints |
Enforce referential integrity in database. Find all referential integrity (foreign key) constraints. |
General |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |