begriffs open source - ai-pg/blob - full-docs/txt/functions-comparisons.txt

   1
   2 9.25. Row and Array Comparisons #
   3
   4    9.25.1. IN
   5    9.25.2. NOT IN
   6    9.25.3. ANY/SOME (array)
   7    9.25.4. ALL (array)
   8    9.25.5. Row Constructor Comparison
   9    9.25.6. Composite Type Comparison
  10
  11    This section describes several specialized constructs for making
  12    multiple comparisons between groups of values. These forms are
  13    syntactically related to the subquery forms of the previous section,
  14    but do not involve subqueries. The forms involving array subexpressions
  15    are PostgreSQL extensions; the rest are SQL-compliant. All of the
  16    expression forms documented in this section return Boolean (true/false)
  17    results.
  18
  19 9.25.1. IN #
  20
  21 expression IN (value [, ...])
  22
  23    The right-hand side is a parenthesized list of expressions. The result
  24    is “true” if the left-hand expression's result is equal to any of the
  25    right-hand expressions. This is a shorthand notation for
  26 expression = value1
  27 OR
  28 expression = value2
  29 OR
  30 ...
  31
  32    Note that if the left-hand expression yields null, or if there are no
  33    equal right-hand values and at least one right-hand expression yields
  34    null, the result of the IN construct will be null, not false. This is
  35    in accordance with SQL's normal rules for Boolean combinations of null
  36    values.
  37
  38 9.25.2. NOT IN #
  39
  40 expression NOT IN (value [, ...])
  41
  42    The right-hand side is a parenthesized list of expressions. The result
  43    is “true” if the left-hand expression's result is unequal to all of the
  44    right-hand expressions. This is a shorthand notation for
  45 expression <> value1
  46 AND
  47 expression <> value2
  48 AND
  49 ...
  50
  51    Note that if the left-hand expression yields null, or if there are no
  52    equal right-hand values and at least one right-hand expression yields
  53    null, the result of the NOT IN construct will be null, not true as one
  54    might naively expect. This is in accordance with SQL's normal rules for
  55    Boolean combinations of null values.
  56
  57 Tip
  58
  59    x NOT IN y is equivalent to NOT (x IN y) in all cases. However, null
  60    values are much more likely to trip up the novice when working with NOT
  61    IN than when working with IN. It is best to express your condition
  62    positively if possible.
  63
  64 9.25.3. ANY/SOME (array) #
  65
  66 expression operator ANY (array expression)
  67 expression operator SOME (array expression)
  68
  69    The right-hand side is a parenthesized expression, which must yield an
  70    array value. The left-hand expression is evaluated and compared to each
  71    element of the array using the given operator, which must yield a
  72    Boolean result. The result of ANY is “true” if any true result is
  73    obtained. The result is “false” if no true result is found (including
  74    the case where the array has zero elements).
  75
  76    If the array expression yields a null array, the result of ANY will be
  77    null. If the left-hand expression yields null, the result of ANY is
  78    ordinarily null (though a non-strict comparison operator could possibly
  79    yield a different result). Also, if the right-hand array contains any
  80    null elements and no true comparison result is obtained, the result of
  81    ANY will be null, not false (again, assuming a strict comparison
  82    operator). This is in accordance with SQL's normal rules for Boolean
  83    combinations of null values.
  84
  85    SOME is a synonym for ANY.
  86
  87 9.25.4. ALL (array) #
  88
  89 expression operator ALL (array expression)
  90
  91    The right-hand side is a parenthesized expression, which must yield an
  92    array value. The left-hand expression is evaluated and compared to each
  93    element of the array using the given operator, which must yield a
  94    Boolean result. The result of ALL is “true” if all comparisons yield
  95    true (including the case where the array has zero elements). The result
  96    is “false” if any false result is found.
  97
  98    If the array expression yields a null array, the result of ALL will be
  99    null. If the left-hand expression yields null, the result of ALL is
 100    ordinarily null (though a non-strict comparison operator could possibly
 101    yield a different result). Also, if the right-hand array contains any
 102    null elements and no false comparison result is obtained, the result of
 103    ALL will be null, not true (again, assuming a strict comparison
 104    operator). This is in accordance with SQL's normal rules for Boolean
 105    combinations of null values.
 106
 107 9.25.5. Row Constructor Comparison #
 108
 109 row_constructor operator row_constructor
 110
 111    Each side is a row constructor, as described in Section 4.2.13. The two
 112    row constructors must have the same number of fields. The given
 113    operator is applied to each pair of corresponding fields. (Since the
 114    fields could be of different types, this means that a different
 115    specific operator could be selected for each pair.) All the selected
 116    operators must be members of some B-tree operator class, or be the
 117    negator of an = member of a B-tree operator class, meaning that row
 118    constructor comparison is only possible when the operator is =, <>, <,
 119    <=, >, or >=, or has semantics similar to one of these.
 120
 121    The = and <> cases work slightly differently from the others. Two rows
 122    are considered equal if all their corresponding members are non-null
 123    and equal; the rows are unequal if any corresponding members are
 124    non-null and unequal; otherwise the result of the row comparison is
 125    unknown (null).
 126
 127    For the <, <=, > and >= cases, the row elements are compared
 128    left-to-right, stopping as soon as an unequal or null pair of elements
 129    is found. If either of this pair of elements is null, the result of the
 130    row comparison is unknown (null); otherwise comparison of this pair of
 131    elements determines the result. For example, ROW(1,2,NULL) < ROW(1,3,0)
 132    yields true, not null, because the third pair of elements are not
 133    considered.
 134 row_constructor IS DISTINCT FROM row_constructor
 135
 136    This construct is similar to a <> row comparison, but it does not yield
 137    null for null inputs. Instead, any null value is considered unequal to
 138    (distinct from) any non-null value, and any two nulls are considered
 139    equal (not distinct). Thus the result will either be true or false,
 140    never null.
 141 row_constructor IS NOT DISTINCT FROM row_constructor
 142
 143    This construct is similar to a = row comparison, but it does not yield
 144    null for null inputs. Instead, any null value is considered unequal to
 145    (distinct from) any non-null value, and any two nulls are considered
 146    equal (not distinct). Thus the result will always be either true or
 147    false, never null.
 148
 149 9.25.6. Composite Type Comparison #
 150
 151 record operator record
 152
 153    The SQL specification requires row-wise comparison to return NULL if
 154    the result depends on comparing two NULL values or a NULL and a
 155    non-NULL. PostgreSQL does this only when comparing the results of two
 156    row constructors (as in Section 9.25.5) or comparing a row constructor
 157    to the output of a subquery (as in Section 9.24). In other contexts
 158    where two composite-type values are compared, two NULL field values are
 159    considered equal, and a NULL is considered larger than a non-NULL. This
 160    is necessary in order to have consistent sorting and indexing behavior
 161    for composite types.
 162
 163    Each side is evaluated and they are compared row-wise. Composite type
 164    comparisons are allowed when the operator is =, <>, <, <=, > or >=, or
 165    has semantics similar to one of these. (To be specific, an operator can
 166    be a row comparison operator if it is a member of a B-tree operator
 167    class, or is the negator of the = member of a B-tree operator class.)
 168    The default behavior of the above operators is the same as for IS [ NOT
 169    ] DISTINCT FROM for row constructors (see Section 9.25.5).
 170
 171    To support matching of rows which include elements without a default
 172    B-tree operator class, the following operators are defined for
 173    composite type comparison: *=, *<>, *<, *<=, *>, and *>=. These
 174    operators compare the internal binary representation of the two rows.
 175    Two rows might have a different binary representation even though
 176    comparisons of the two rows with the equality operator is true. The
 177    ordering of rows under these comparison operators is deterministic but
 178    not otherwise meaningful. These operators are used internally for
 179    materialized views and might be useful for other specialized purposes
 180    such as replication and B-Tree deduplication (see Section 65.1.4.3).
 181    They are not intended to be generally useful for writing queries,
 182    though.