Filter Queries
Found 9 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 relatively small amount of data, which is in the system catalog of a database.
- Statistics about the catalog content and project home in GitHub that has additional information.
#1. Columns with a range type that require a better name
INFORMATION_SCHEMA onlyThis query identifies columns with a RANGE data type that violate naming conventions. It flags columns whose names do not semantically suggest a range or period, which can create ambiguity and lead to incorrect assumptions when writing queries.
#2. Enumerated or range types with the same name in different schemas
INFORMATION_SCHEMA+system catalog base tablesThis query enforces the Don't Repeat Yorself principle across the database's type system. It identifies ENUM and RANGE types that share the same name but exist in different schemas. This indicates that a conceptual data type has been defined multiple times instead of having a single, canonical definition in a shared schema. Such duplication leads to maintenance overhead and the risk of semantic divergence over time.
#3. Perhaps the type of a base table column should be TSTZRANGE
INFORMATION_SCHEMA onlyThis query identifies all base table columns defined with the range of timestamp without zone data type. Use of this data type is a potential design flaw as it can lead to ambiguity and bugs when handling data from multiple time zones.
#4. Range lower bound can be NULL
INFORMATION_SCHEMA+system catalog base tablesThis query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL lower bound. This highlights ranges that can be "unbounded" on their starting side, which may be unintentional and could impact query logic and data constraints.
#5. Range lower bound is not restricted
INFORMATION_SCHEMA+system catalog base tablesThis query finds range columns of base tables that are missing a safety check on their starting value. It looks for columns where the start of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their starting points.
#6. Range lower bound restriction does not consider -infinity
INFORMATION_SCHEMA+system catalog base tablesThis query identifies RANGE type columns in base tables that have a NOT NULL constraint on their lower bound and an additional CHECK constraint, but this check does not account for -infinity. This may indicate a "magic number" problem, where a fixed lower limit (e.g., '1900-01-01') is used instead of the more explicit and semantically correct unbounded (-infinity) value.
#7. Range upper bound can be NULL
INFORMATION_SCHEMA+system catalog base tablesThis query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL upper bound. This highlights ranges that can be "unbounded" on their ending side, which may be unintentional and could impact query logic and data constraints.
#8. Range upper bound is not restricted
INFORMATION_SCHEMA+system catalog base tablesThis query finds range columns of base tables that are missing a safety check on their ending value. It looks for columns where the end of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their ending points.
#9. Range upper bound restriction dos not consider infinity
INFORMATION_SCHEMA+system catalog base tablesThis query identifies RANGE type columns in base tables that have a NOT NULL constraint on their upper bound and an additional CHECK constraint, but this check does not account for infinity. This may indicate a "magic number" problem, where a fixed upper limit (e.g., '2900-01-01') is used instead of the more explicit and semantically correct unbounded (infinity) value.
| # | Name (sorted ascending) | Goal | Type | Data source | Last update | License | Actions |
|---|---|---|---|---|---|---|---|
| 1 | Columns with a range type that require a better name | This query identifies columns with a RANGE data type that violate naming conventions. It flags columns whose names do not semantically suggest a range or period, which can create ambiguity and lead to incorrect assumptions when writing queries. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 2 | Enumerated or range types with the same name in different schemas | This query enforces the Don't Repeat Yorself principle across the database's type system. It identifies ENUM and RANGE types that share the same name but exist in different schemas. This indicates that a conceptual data type has been defined multiple times instead of having a single, canonical definition in a shared schema. Such duplication leads to maintenance overhead and the risk of semantic divergence over time. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 3 | Perhaps the type of a base table column should be TSTZRANGE | This query identifies all base table columns defined with the range of timestamp without zone data type. Use of this data type is a potential design flaw as it can lead to ambiguity and bugs when handling data from multiple time zones. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 4 | Range lower bound can be NULL | This query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL lower bound. This highlights ranges that can be "unbounded" on their starting side, which may be unintentional and could impact query logic and data constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 5 | Range lower bound is not restricted | This query finds range columns of base tables that are missing a safety check on their starting value. It looks for columns where the start of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their starting points. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 6 | Range lower bound restriction does not consider -infinity | This query identifies RANGE type columns in base tables that have a NOT NULL constraint on their lower bound and an additional CHECK constraint, but this check does not account for -infinity. This may indicate a "magic number" problem, where a fixed lower limit (e.g., '1900-01-01') is used instead of the more explicit and semantically correct unbounded (-infinity) value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 7 | Range upper bound can be NULL | This query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL upper bound. This highlights ranges that can be "unbounded" on their ending side, which may be unintentional and could impact query logic and data constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 8 | Range upper bound is not restricted | This query finds range columns of base tables that are missing a safety check on their ending value. It looks for columns where the end of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their ending points. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 9 | Range upper bound restriction dos not consider infinity | This query identifies RANGE type columns in base tables that have a NOT NULL constraint on their upper bound and an additional CHECK constraint, but this check does not account for infinity. This may indicate a "magic number" problem, where a fixed upper limit (e.g., '2900-01-01') is used instead of the more explicit and semantically correct unbounded (infinity) value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) |