Filter Queries

Found 1056 queries.

  • All the queries about database objects contain a subcondition to exclude from the result information about the system catalog.
  • Although the statements use SQL constructs (common table expressions; NOT in subqueries) that could cause performance problems in case of large datasets, it shouldn't be a problem in case of the relatively small amount of data in the system catalog of a database.

#941. Useless type indication

INFORMATION_SCHEMA+system catalog base tables

Find columns and parameters where the type of the identifier is perhaps explicitly indicated in the name.

Problem detection License: MIT (opens in new tab)

#942. Useless type indication (2)

INFORMATION_SCHEMA+system catalog base tables

Find columns and parameters where the type of the identifier is perhaps explicitly indicated in the name.

Problem detection License: MIT (opens in new tab)

#943. User-defined routine execution privilege has been granted to PUBLIC

INFORMATION_SCHEMA+system catalog base tables

You should follow the principle of least privilege and thus not have in your database user-defined routines that execution privilege is granted to PUBLIC, i.e., to all the database users now and in the future. By default, PostgreSQL gives routine execution privileges to PUBLIC.

Problem detection License: MIT (opens in new tab)

#944. User-defined routines that have the same name as some system-defined routine.

INFORMATION_SCHEMA+system catalog base tables

Avoid creating user-defined routines that have the same name as some system-defined routine because it may cause confusion.

Problem detection License: MIT (opens in new tab)

#945. User-defined routines that use dynamic SQL to execute data manipulation statements

INFORMATION_SCHEMA+system catalog base tables

Find user-defined routines that use dynamic SQL to execute data manipulation statements (SELECT, INSERT, UPDATE, DELETE).

Problem detection License: MIT (opens in new tab)

#946. User-defined routines that use keyword DECLARE but do not declare anything

INFORMATION_SCHEMA+system catalog base tables

Find user-defined routines that use keyword DECLARE but do not declare anything.

Problem detection License: MIT (opens in new tab)

#947. User-defined routines that use md5 hash for other purposes than generating test data

INFORMATION_SCHEMA+system catalog base tables

Find user-defined routines that use md5 hashes for the security purposes. Nowadays such hashes can be calculated too quickly and its use should be avoided at least for hashing passwords. Exclude routines that invoke both md5 function and generate_series function and are thus probably used to generate test data.

Problem detection License: MIT (opens in new tab)

#948. User-defined routines that use positional references to parameters

INFORMATION_SCHEMA+system catalog base tables

Use parameter names instead of positional references to improve code evolvability.

Problem detection License: MIT (opens in new tab)

#949. User-defined routines with dynamic SQL that are potential targets of the SQL injection attack

INFORMATION_SCHEMA+system catalog base tables

Find routines that have at least one input parameter, use dynamic SQL but do not escape the input arguments at all.

Problem detection License: MIT (opens in new tab)

#950. Username is not unique

INFORMATION_SCHEMA+system catalog base tables

Find textual columns that potentially contain usernames (including columns that potentially contain e-mail addresses) that do not have a unique constraint or a unique index that involves only this column.

Problem detection License: MIT (opens in new tab)

#951. Using AFTER triggers to enforce constraints

INFORMATION_SCHEMA+system catalog base tables

Do not let the system to do extra work. Checking a constraint with an AFTER trigger means that the trigger procedure will be executed after the data modification and if the check fails, then the system has to do extra work to roll back the changes.

Problem detection License: MIT (opens in new tab)

#952. Using BEFORE triggers to log data changes

INFORMATION_SCHEMA+system catalog base tables

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 License: MIT (opens in new tab)

#953. Using conditionals to determine the returned value

INFORMATION_SCHEMA+system catalog base tables

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 License: MIT (opens in new tab)

#954. Using in some way reserved (in PostgreSQL) SQL keywords as the names of a database object (aggregate view)

INFORMATION_SCHEMA+system catalog base tables

"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 License: MIT (opens in new tab)

#955. Using in some way reserved (in PostgreSQL) SQL keywords as the names of a database object (detailed view)

INFORMATION_SCHEMA+system catalog base tables

"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 License: MIT (opens in new tab)

#956. Using routine name in front of a parameter name in a routine body to refer to the parameter of the routine

INFORMATION_SCHEMA+system catalog base tables

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 License: MIT (opens in new tab)

#957. Using system-defined names of constraints (constraints that involve more than one column)

system catalog base tables only

Find the constraint types in case of which there exists system-defined names.

Problem detection License: MIT (opens in new tab)

#958. Using system-defined names of constraints (constraints that involve one column)

system catalog base tables only

Find the constraint types in case of which there exists system-defined names.

Problem detection License: MIT (opens in new tab)

#959. Using unreserved (in PostgreSQL) SQL keywords as the names of a database object (aggregate view)

INFORMATION_SCHEMA+system catalog base tables

"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 License: MIT (opens in new tab)

#960. Using unreserved (in PostgreSQL) SQL keywords as the names of a database object (detailed view)

INFORMATION_SCHEMA+system catalog base tables

"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 License: MIT (opens in new tab)
# Name(activate to sort ascending) Goal(activate to sort ascending) Type(sorted ascending, activate to sort descending) Data source(activate to sort ascending) Last update(activate to sort ascending) License Actions
941 Useless type indication Find columns and parameters where the type of the identifier is perhaps explicitly indicated in the name. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
942 Useless type indication (2) Find columns and parameters where the type of the identifier is perhaps explicitly indicated in the name. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
943 User-defined routine execution privilege has been granted to PUBLIC You should follow the principle of least privilege and thus not have in your database user-defined routines that execution privilege is granted to PUBLIC, i.e., to all the database users now and in the future. By default, PostgreSQL gives routine execution privileges to PUBLIC. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
944 User-defined routines that have the same name as some system-defined routine. Avoid creating user-defined routines that have the same name as some system-defined routine because it may cause confusion. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
945 User-defined routines that use dynamic SQL to execute data manipulation statements Find user-defined routines that use dynamic SQL to execute data manipulation statements (SELECT, INSERT, UPDATE, DELETE). Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
946 User-defined routines that use keyword DECLARE but do not declare anything Find user-defined routines that use keyword DECLARE but do not declare anything. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
947 User-defined routines that use md5 hash for other purposes than generating test data Find user-defined routines that use md5 hashes for the security purposes. Nowadays such hashes can be calculated too quickly and its use should be avoided at least for hashing passwords. Exclude routines that invoke both md5 function and generate_series function and are thus probably used to generate test data. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
948 User-defined routines that use positional references to parameters Use parameter names instead of positional references to improve code evolvability. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
949 User-defined routines with dynamic SQL that are potential targets of the SQL injection attack Find routines that have at least one input parameter, use dynamic SQL but do not escape the input arguments at all. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
950 Username is not unique Find textual columns that potentially contain usernames (including columns that potentially contain e-mail addresses) that do not have a unique constraint or a unique index that involves only this column. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
951 Using AFTER triggers to enforce constraints Do not let the system to do extra work. Checking a constraint with an AFTER trigger means that the trigger procedure will be executed after the data modification and if the check fails, then the system has to do extra work to roll back the changes. Problem detection INFORMATION_SCHEMA+system catalog base tables MIT (opens in new tab) View (opens in new tab)
952 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 MIT (opens in new tab) View (opens in new tab)
953 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 MIT (opens in new tab) View (opens in new tab)
954 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 MIT (opens in new tab) View (opens in new tab)
955 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 MIT (opens in new tab) View (opens in new tab)
956 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 MIT (opens in new tab) View (opens in new tab)
957 Using system-defined names of constraints (constraints that involve more than one column) Find the constraint types in case of which there exists system-defined names. Problem detection system catalog base tables only MIT (opens in new tab) View (opens in new tab)
958 Using system-defined names of constraints (constraints that involve one column) Find the constraint types in case of which there exists system-defined names. Problem detection system catalog base tables only MIT (opens in new tab) View (opens in new tab)
959 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 MIT (opens in new tab) View (opens in new tab)
960 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 MIT (opens in new tab) View (opens in new tab)