PostgreSQL Query Catalog

This query identifies columns in views (derived tables) whose names suggest they store a person's name but lack context about the person's role. In a view, a column containing a person's name should indicate their specific role regarding the entity. For example, a column simply named surname in an active_product view is ambiguous; a more descriptive name, such as registrar_surname, is preferred. However, if the primary purpose of the view is to present personal data, generic names like surname are perfectly acceptable.

"Avoid using the same word for two purposes. Using the same term for two different ideas is essentially a pun" (Robert C. Martin, Clean Code) Do not use the Estonian words like 'lisa', 'muuda', 'kustuta' or the corresponding English words 'add', 'delete', 'update' as the names of routines because it would make the code much less understandable. What is the task of the routine f_add? Register people? Register orders? What? Do not refer to the generic concepts like data and information because all routines work with these.

Find table constraints (constraints that are associated directly with the table) that have too generic names like "key" or the name contain too generic words like "data" (all constraints restrict data in the table), or the name is an abbreviation of a constraint type name.

This query identifies tables with semantically weak, generic names that violate schema design best practices. It flags tables with name components such as "table", "data", "information", or "list". The principle is that a table name should accurately represent the real-world entity it models. Using generic nouns obscures the schema's meaning, reduces readability, and forces developers to inspect the table's contents to understand its purpose.

Find unique index (not associated with a constraint) columns with the names like id, identifikaator, code, kood, number, etc. The names could have underscores as the prefix or suffix. These are too generic names.

Find unique indexes that have too generic names like "key" or the name contain too generic words like "data" (all constraints restrict data in the table), or the name is an abbreviation of a constraint type name.

Find names of user-defined types and domains that contain too generic (noise) words.

Find patterns of regular expressions where more than \ is written instead of \, e.g., \\s is used instead of \s to refer to a character class.

Find names of domain constraints that are shorter than the length of the name of the domain + two characters.

"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) The names should be meaningful and searchable. Find the names (identifiers) of user-defined database objects that are shorter than three characters.

Find views, materialized views, and user-defined routines that do not have a comment at all or the comment is shorter than twice the length of the object name, or the comment states that it is missing (TODO). You should give information to future developers and maintainers of the system (including the future version of yourself). Do not just repeat the name in the comment (with perhaps some rewording).

The names should be expressive. Find names of constraints, which are associated directly to a table, that are shorter than the length of the name of the table + two characters.

Names should be expressive. Find views that name is shorter than the average length of the the names of its directly underlying tables (both base tables and derived tables).

Find composite indexes that do not support any constraint but are on more than three columns.

Find derived tables (views, materialized views) that are based on more than five tables and that have more than 15 columns. This view might produce "a denormalized world view" where all the data is together in one table and applications make queries based on this single view to fulfill their specific tasks. Such view does not follow the separation of concerns principle.

Find user-defined SQL and PL/pgSQL routines that do not return a value although the name suggest that it should return a value (contains "_to_").

This query performs a semantic analysis of trigger function comments to identify potential violations of separation of concerns. It flags triggers whose documentation references explicit database operations (e.g., OP1, OP2) but lacks terminology associated with validation or invariant enforcement (e.g., "check", "ensure", "validate"). This linguistic pattern suggests that the trigger may be improperly implementing the business operation itself (a side effect) rather than serving its primary role as an integrity guardrail, or that the documentation inaccurately reflects the trigger's behavior.

Find trigger functions that contain a conditional (IF or CASE) but do not contain a SELECT statement before these. The latter condition is for the reason that one cannot use a subquery in the WHEN clause. Thus, if one wants to make a query and decide the further action based on the results of the query, then one must do it within the body of the function.

Find tables where user-defined (non-system) triggers are used to implement referential integrity. In addition to table name show the triggers and the number of triggers.

Automatically defined TG_OP variable in a trigger function has data type text. Its value is a string of INSERT, UPDATE, DELETE, or TRUNCATE telling for which operation the trigger was fired. Find the routines that according to the TG_OP value must react to a certain operation but the routine is not associated with any triggers that are fired by the operation. For instance, the routine specifies reaction to DELETE operation but the routine is not associated with any DELETE trigger.