PostgreSQL Query Catalog

Find base table columns that name refers to the possibility that there are registered deadlines but the column does not have a temporal type.

Find base table columns that have CHAR type, where character maximum length is bigger than 1 and the name of the column does not refer to the possibility that the column holds some kind of codes or flags or hash values.

Find columns of base tables where the name of the column has prefix or suffix "id" or has the name "id" but the column does not have an integer type or uuid type. A convention is to use the phrase "id" in the names of surrogate key columns.

Find base table columns that have an enumerated type that seems to emulate Boolean type.

Find base table columns that name refers to the possibility that these are used to register XML/JSON values. Find the columns that do not have an appropriate data type (xml, json, jsonb). One shouldn't use columns with a textual type to register such data.

Find routine parameters that based on the name seem to hold truth values. Find parameters that name starts with "is_" or "has_" or "can_" or "on_" and that do not have Boolean type.

One should be consistent in naming, including in the use of prefixes. If you use prefix in the name of a database object, then it should refer to the type of the database object. Do not use different prefixes in the names of database objects that have the same type. Find types of database objects in case of which there are different prefixes in different names.

One should be consistent in naming, including in the use of suffixes. If you use sufix in the name of a database object, then it should refer to the type of the database object. Do not use different suffixes in the names of database objects that have the same type. Find types of database objects in case of which there are different suffixes in different names.

Too many parameters (in this case four or more) could be a sign of not separating concerns and having a routine that has more than one task.

Character classes are surrounded by two pairs of square brackets.

Find check constraints of base table and foreign table columns that are either associated with more than one column and have at least one AND operation or are associated with exactly one column and have two or more AND operations.

Find PL/pgSQL routines that perhaps unnecessarily contain DECLARE section. More specifically, find routines with the DECLARE section where the only task seems to be raising an exception. The query excludes the cases where the error message is constructed dynamically, i.e., in this case using a variable maybe justifiable.

Find PL/pgSQL routines that perhaps unnecessarily contain DECLARE section. More specifically, find routines with the DECLARE section where the keyword DECLARE is followed by BEGIN, i.e., the DECLARE section is empty.

Find as to whether a database user (except postgres), who is not a superuser, has Create (C) or Temporary (T) privileges to use the database.

Find routines with SQL-standard body that seem to update data in a table that has a column for modification time but the routine does not seem to update the modification time while updating the row and the table does not seem to have an UPDATE trigger that changes the modification time.

Find all primary key and unique constraints of base tables that involve at least one column with personal names. Personal names are not unique and these cannot be (usually) used to guarantee uniqueness. Either one has declared a superkey instead of candidate key (i.e., the key contains a column that is not needed for uniqueness) or the key columns have been found incorrectly.

Find PL/pgSQL functions with consecutive RETURN clauses. Only the first RETURN will be used, others are unnecessary.

The return value of a function cannot be left undefined. If control reaches the end of the top-level block of the function without hitting a RETURN statement, a run-time error will occur. This restriction does not apply to functions with output parameters and functions returning void, however. In those cases a RETURN statement is automatically executed if the top-level block finishes. It also does not apply to trigger functions that only task is to raise an exception.

Working with sets of rows rather than processing each row separately is more effective.

Find PL/pgSQL that contain a SELECT statement that is not a SELECT … INTO statement. This is not permitted in PL/pgSQL routines.