{"kind": "locale", "major": "18", "item": {"slug": "provider-builtin", "name": "builtin", "name_zh": "", "category": "Collation provider identities", "summary": "builtin collation provider.", "aliases": [], "content_hash": "11355b46a77004baf447edc1b8e4ab2b4f172daf8c239389472f9a79ed03b038", "versions": {"17": {"facts": [{"label": "Provider", "value": "builtin"}, {"label": "Catalog code", "value": "b"}, {"label": "Scope", "value": "Source provider identity; installation/build availability is separate"}], "tables": [], "aliases": [], "related": [], "release": {"ref": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "label": "17.11", "major": "17", "channel": "stable", "revision": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979", "source_sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979", "catalog_fingerprint": "4bbe3ac77becd618478f66aec420a533e9017be356c5c1d51a4b17f0fd497c07"}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v17.11/postgresql-17.11.tar.bz2", "label": "Matching PostgreSQL source archive", "sha256": "dd27f2b3c59e73ed14aa3324901242bf69a032a6347805f274e6260322d42979"}, {"url": "/docs/17/collation.html#COLLATION-CONCEPTS", "path": "collation.html", "label": "PostgreSQL 17 English manual", "sha256": "67aac7b4c281b861af98f8f644ba2c3381358ffed48a74134fc269d0ae968029"}], "sections": [], "signature": "", "attributes": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "description": ["builtin collation provider."], "manual_html": "
\n
\n
\n
\n

23.2.1.\u00a0Concepts

\n
\n
\n
\n

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are text, varchar, and char. User-defined base types can also be marked collatable, and of course a domain over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below.

\n

The collation of an expression can be the \u201cdefault\u201d collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail.

\n

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with ORDER BY clauses and function or operator calls such as <. The collation to apply for an ORDER BY clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as lower, upper, and initcap; by pattern matching operators; and by to_char and related functions.

\n

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation.

\n

The collation derivation of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a COLLATE clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used:

\n
\n
    \n
  1. \n

    If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination.

    \n
    2. \n
  2. \n

    Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation.

    \n
    3. \n
  3. \n

    If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time.

    \n
    4. \n
\n
\n

For example, consider this table definition:

\n
CREATE TABLE test1 (\n    a text COLLATE \"de_DE\",\n    b text COLLATE \"es_ES\",\n    ...\n);\n
\n

Then in

\n
SELECT a < 'foo' FROM test1;\n
\n

the < comparison is performed according to de_DE rules, because the expression combines an implicitly derived collation with the default collation. But in

\n
SELECT a < ('foo' COLLATE \"fr_FR\") FROM test1;\n
\n

the comparison is performed using fr_FR rules, because the explicit collation derivation overrides the implicit one. Furthermore, given

\n
SELECT a < b FROM test1;\n
\n

the parser cannot determine which collation to apply, since the a and b columns have conflicting implicit collations. Since the < operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus:

\n
SELECT a < b COLLATE \"de_DE\" FROM test1;\n
\n

or equivalently

\n
SELECT a COLLATE \"de_DE\" < b FROM test1;\n
\n

On the other hand, the structurally similar case

\n
SELECT a || b FROM test1;\n
\n

does not result in an error, because the || operator does not care about collations: its result is the same regardless of the collation.

\n

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in

\n
SELECT * FROM test1 ORDER BY a || 'foo';\n
\n

the ordering will be done according to de_DE rules. But this query:

\n
SELECT * FROM test1 ORDER BY a || b;\n
\n

results in an error, because even though the || operator doesn't need to know a collation, the ORDER BY clause does. As before, the conflict can be resolved with an explicit collation specifier:

\n
SELECT * FROM test1 ORDER BY a || b COLLATE \"fr_FR\";\n
\n
", "manual_path": "/docs/17/collation.html#COLLATION-CONCEPTS", "comparison_data": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "comparison_hash": "d0ee87b3545cc68aafaa491d16e6d3a73ddc2ded39dd20ba234b922cd06fd397"}, "18": {"facts": [{"label": "Provider", "value": "builtin"}, {"label": "Catalog code", "value": "b"}, {"label": "Scope", "value": "Source provider identity; installation/build availability is separate"}], "tables": [], "aliases": [], "related": [], "release": {"ref": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "18.6", "major": "18", "channel": "stable", "revision": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "catalog_fingerprint": "65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502"}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "Matching PostgreSQL source archive", "sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/collation.html#COLLATION-CONCEPTS", "path": "collation.html", "label": "PostgreSQL 18 English manual", "sha256": "c98cbca2b2235a896f7fe438a88a99b8d6b9d1f50bdb49fe2794e9982a50797f"}], "sections": [], "signature": "", "attributes": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "description": ["builtin collation provider."], "manual_html": "
\n
\n
\n
\n

23.2.1.\u00a0Concepts

\n
\n
\n
\n

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are text, varchar, and char. User-defined base types can also be marked collatable, and of course a domain over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below.

\n

The collation of an expression can be the \u201cdefault\u201d collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail.

\n

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with ORDER BY clauses and function or operator calls such as <. The collation to apply for an ORDER BY clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as lower, upper, and initcap; by pattern matching operators; and by to_char and related functions.

\n

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation.

\n

The collation derivation of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a COLLATE clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used:

\n
\n
    \n
  1. \n

    If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination.

    \n
    2. \n
  2. \n

    Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation.

    \n
    3. \n
  3. \n

    If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time.

    \n
    4. \n
\n
\n

For example, consider this table definition:

\n
CREATE TABLE test1 (\n    a text COLLATE \"de_DE\",\n    b text COLLATE \"es_ES\",\n    ...\n);\n
\n

Then in

\n
SELECT a < 'foo' FROM test1;\n
\n

the < comparison is performed according to de_DE rules, because the expression combines an implicitly derived collation with the default collation. But in

\n
SELECT a < ('foo' COLLATE \"fr_FR\") FROM test1;\n
\n

the comparison is performed using fr_FR rules, because the explicit collation derivation overrides the implicit one. Furthermore, given

\n
SELECT a < b FROM test1;\n
\n

the parser cannot determine which collation to apply, since the a and b columns have conflicting implicit collations. Since the < operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus:

\n
SELECT a < b COLLATE \"de_DE\" FROM test1;\n
\n

or equivalently

\n
SELECT a COLLATE \"de_DE\" < b FROM test1;\n
\n

On the other hand, the structurally similar case

\n
SELECT a || b FROM test1;\n
\n

does not result in an error, because the || operator does not care about collations: its result is the same regardless of the collation.

\n

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in

\n
SELECT * FROM test1 ORDER BY a || 'foo';\n
\n

the ordering will be done according to de_DE rules. But this query:

\n
SELECT * FROM test1 ORDER BY a || b;\n
\n

results in an error, because even though the || operator doesn't need to know a collation, the ORDER BY clause does. As before, the conflict can be resolved with an explicit collation specifier:

\n
SELECT * FROM test1 ORDER BY a || b COLLATE \"fr_FR\";\n
\n
", "manual_path": "/docs/18/collation.html#COLLATION-CONCEPTS", "comparison_data": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "comparison_hash": "d0ee87b3545cc68aafaa491d16e6d3a73ddc2ded39dd20ba234b922cd06fd397"}, "19": {"facts": [{"label": "Provider", "value": "builtin"}, {"label": "Catalog code", "value": "b"}, {"label": "Scope", "value": "Source provider identity; installation/build availability is separate"}], "tables": [], "aliases": [], "related": [], "release": {"ref": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "label": "19beta4", "major": "19", "channel": "preview", "revision": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86", "source_sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86", "catalog_fingerprint": "62fbf1a3689dbe8bf7e6b3372cfe6fbf867581427b3858a94c8419b77a4d2d1d"}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v19beta4/postgresql-19beta4.tar.bz2", "label": "Matching PostgreSQL source archive", "sha256": "83157ee9c599d03b2f7a3d73ef3a56ec24e0e79cc2b3501a64d1364f56398c86"}, {"url": "/docs/19/collation.html#COLLATION-CONCEPTS", "path": "collation.html", "label": "PostgreSQL 19 English manual", "sha256": "2eef5fdde9bbc23617bb28de2a76a46c48b5a51662dc9212b1ceb56a85199a5e"}], "sections": [], "signature": "", "attributes": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "description": ["builtin collation provider."], "manual_html": "
\n
\n
\n
\n

23.2.1.\u00a0Concepts

\n
\n
\n
\n

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are text, varchar, and char. User-defined base types can also be marked collatable, and of course a domain over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below.

\n

The collation of an expression can be the \u201cdefault\u201d collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail.

\n

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with ORDER BY clauses and function or operator calls such as <. The collation to apply for an ORDER BY clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as lower, upper, and initcap; by pattern matching operators; and by to_char and related functions.

\n

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation.

\n

The collation derivation of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a COLLATE clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used:

\n
\n
    \n
  1. \n

    If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination.

    \n
    2. \n
  2. \n

    Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation.

    \n
    3. \n
  3. \n

    If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time.

    \n
    4. \n
\n
\n

For example, consider this table definition:

\n
CREATE TABLE test1 (\n    a text COLLATE \"de_DE\",\n    b text COLLATE \"es_ES\",\n    ...\n);\n
\n

Then in

\n
SELECT a < 'foo' FROM test1;\n
\n

the < comparison is performed according to de_DE rules, because the expression combines an implicitly derived collation with the default collation. But in

\n
SELECT a < ('foo' COLLATE \"fr_FR\") FROM test1;\n
\n

the comparison is performed using fr_FR rules, because the explicit collation derivation overrides the implicit one. Furthermore, given

\n
SELECT a < b FROM test1;\n
\n

the parser cannot determine which collation to apply, since the a and b columns have conflicting implicit collations. Since the < operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus:

\n
SELECT a < b COLLATE \"de_DE\" FROM test1;\n
\n

or equivalently

\n
SELECT a COLLATE \"de_DE\" < b FROM test1;\n
\n

On the other hand, the structurally similar case

\n
SELECT a || b FROM test1;\n
\n

does not result in an error, because the || operator does not care about collations: its result is the same regardless of the collation.

\n

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in

\n
SELECT * FROM test1 ORDER BY a || 'foo';\n
\n

the ordering will be done according to de_DE rules. But this query:

\n
SELECT * FROM test1 ORDER BY a || b;\n
\n

results in an error, because even though the || operator doesn't need to know a collation, the ORDER BY clause does. As before, the conflict can be resolved with an explicit collation specifier:

\n
SELECT * FROM test1 ORDER BY a || b COLLATE \"fr_FR\";\n
\n
", "manual_path": "/docs/19/collation.html#COLLATION-CONCEPTS", "comparison_data": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "comparison_hash": "d0ee87b3545cc68aafaa491d16e6d3a73ddc2ded39dd20ba234b922cd06fd397"}, "20": {"facts": [{"label": "Provider", "value": "builtin"}, {"label": "Catalog code", "value": "b"}, {"label": "Scope", "value": "Source provider identity; installation/build availability is separate"}], "tables": [], "aliases": [], "related": [], "release": {"ref": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "label": "20devel", "major": "20", "channel": "devel", "revision": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41", "source_sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41", "catalog_fingerprint": "398fbb9f262264053c02fbf79f88be0a6770c1473faa6ecd5931d6ec41b8258b", "source_snapshot_utc": "26-Sep-2026 20:22"}, "sources": [{"url": "https://ftp.postgresql.org/pub/snapshot/dev/postgresql-snapshot.tar.bz2", "label": "Matching PostgreSQL source archive", "sha256": "4d3346909b201ac1648232cf290462a7070c119326f56196f1f0253ed80fae41"}, {"url": "/docs/devel/collation.html#COLLATION-CONCEPTS", "path": "collation.html", "label": "PostgreSQL 20 English manual", "sha256": "3a5f2e6c1df8548d2a7d1f654dfc8fe598c1ce90f62169c3a2d11d8c736f940e"}], "sections": [], "signature": "", "attributes": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "description": ["builtin collation provider."], "manual_html": "
\n
\n
\n
\n

23.2.1.\u00a0Concepts

\n
\n
\n
\n

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are text, varchar, and char. User-defined base types can also be marked collatable, and of course a domain over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below.

\n

The collation of an expression can be the \u201cdefault\u201d collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail.

\n

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with ORDER BY clauses and function or operator calls such as <. The collation to apply for an ORDER BY clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as lower, upper, and initcap; by pattern matching operators; and by to_char and related functions.

\n

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation.

\n

The collation derivation of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a COLLATE clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used:

\n
\n
    \n
  1. \n

    If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination.

    \n
    2. \n
  2. \n

    Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation.

    \n
    3. \n
  3. \n

    If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time.

    \n
    4. \n
\n
\n

For example, consider this table definition:

\n
CREATE TABLE test1 (\n    a text COLLATE \"de_DE\",\n    b text COLLATE \"es_ES\",\n    ...\n);\n
\n

Then in

\n
SELECT a < 'foo' FROM test1;\n
\n

the < comparison is performed according to de_DE rules, because the expression combines an implicitly derived collation with the default collation. But in

\n
SELECT a < ('foo' COLLATE \"fr_FR\") FROM test1;\n
\n

the comparison is performed using fr_FR rules, because the explicit collation derivation overrides the implicit one. Furthermore, given

\n
SELECT a < b FROM test1;\n
\n

the parser cannot determine which collation to apply, since the a and b columns have conflicting implicit collations. Since the < operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus:

\n
SELECT a < b COLLATE \"de_DE\" FROM test1;\n
\n

or equivalently

\n
SELECT a COLLATE \"de_DE\" < b FROM test1;\n
\n

On the other hand, the structurally similar case

\n
SELECT a || b FROM test1;\n
\n

does not result in an error, because the || operator does not care about collations: its result is the same regardless of the collation.

\n

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in

\n
SELECT * FROM test1 ORDER BY a || 'foo';\n
\n

the ordering will be done according to de_DE rules. But this query:

\n
SELECT * FROM test1 ORDER BY a || b;\n
\n

results in an error, because even though the || operator doesn't need to know a collation, the ORDER BY clause does. As before, the conflict can be resolved with an explicit collation specifier:

\n
SELECT * FROM test1 ORDER BY a || b COLLATE \"fr_FR\";\n
\n
", "manual_path": "/docs/devel/collation.html#COLLATION-CONCEPTS", "comparison_data": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "comparison_hash": "d0ee87b3545cc68aafaa491d16e6d3a73ddc2ded39dd20ba234b922cd06fd397"}}}, "snapshot": {"facts": [{"label": "Provider", "value": "builtin"}, {"label": "Catalog code", "value": "b"}, {"label": "Scope", "value": "Source provider identity; installation/build availability is separate"}], "tables": [], "aliases": [], "related": [], "release": {"ref": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "18.6", "major": "18", "channel": "stable", "revision": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "source_sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f", "catalog_fingerprint": "65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502"}, "sources": [{"url": "https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2", "label": "Matching PostgreSQL source archive", "sha256": "555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}, {"url": "/docs/18/collation.html#COLLATION-CONCEPTS", "path": "collation.html", "label": "PostgreSQL 18 English manual", "sha256": "c98cbca2b2235a896f7fe438a88a99b8d6b9d1f50bdb49fe2794e9982a50797f"}], "sections": [], "signature": "", "attributes": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "description": ["builtin collation provider."], "manual_html": "
\n
\n
\n
\n

23.2.1.\u00a0Concepts

\n
\n
\n
\n

Conceptually, every expression of a collatable data type has a collation. (The built-in collatable data types are text, varchar, and char. User-defined base types can also be marked collatable, and of course a domain over a collatable data type is collatable.) If the expression is a column reference, the collation of the expression is the defined collation of the column. If the expression is a constant, the collation is the default collation of the data type of the constant. The collation of a more complex expression is derived from the collations of its inputs, as described below.

\n

The collation of an expression can be the \u201cdefault\u201d collation, which means the locale settings defined for the database. It is also possible for an expression's collation to be indeterminate. In such cases, ordering operations and other operations that need to know the collation will fail.

\n

When the database system has to perform an ordering or a character classification, it uses the collation of the input expression. This happens, for example, with ORDER BY clauses and function or operator calls such as <. The collation to apply for an ORDER BY clause is simply the collation of the sort key. The collation to apply for a function or operator call is derived from the arguments, as described below. In addition to comparison operators, collations are taken into account by functions that convert between lower and upper case letters, such as lower, upper, and initcap; by pattern matching operators; and by to_char and related functions.

\n

For a function or operator call, the collation that is derived by examining the argument collations is used at run time for performing the specified operation. If the result of the function or operator call is of a collatable data type, the collation is also used at parse time as the defined collation of the function or operator expression, in case there is a surrounding expression that requires knowledge of its collation.

\n

The collation derivation of an expression can be implicit or explicit. This distinction affects how collations are combined when multiple different collations appear in an expression. An explicit collation derivation occurs when a COLLATE clause is used; all other collation derivations are implicit. When multiple collations need to be combined, for example in a function call, the following rules are used:

\n
\n
    \n
  1. \n

    If any input expression has an explicit collation derivation, then all explicitly derived collations among the input expressions must be the same, otherwise an error is raised. If any explicitly derived collation is present, that is the result of the collation combination.

    \n
    2. \n
  2. \n

    Otherwise, all input expressions must have the same implicit collation derivation or the default collation. If any non-default collation is present, that is the result of the collation combination. Otherwise, the result is the default collation.

    \n
    3. \n
  3. \n

    If there are conflicting non-default implicit collations among the input expressions, then the combination is deemed to have indeterminate collation. This is not an error condition unless the particular function being invoked requires knowledge of the collation it should apply. If it does, an error will be raised at run-time.

    \n
    4. \n
\n
\n

For example, consider this table definition:

\n
CREATE TABLE test1 (\n    a text COLLATE \"de_DE\",\n    b text COLLATE \"es_ES\",\n    ...\n);\n
\n

Then in

\n
SELECT a < 'foo' FROM test1;\n
\n

the < comparison is performed according to de_DE rules, because the expression combines an implicitly derived collation with the default collation. But in

\n
SELECT a < ('foo' COLLATE \"fr_FR\") FROM test1;\n
\n

the comparison is performed using fr_FR rules, because the explicit collation derivation overrides the implicit one. Furthermore, given

\n
SELECT a < b FROM test1;\n
\n

the parser cannot determine which collation to apply, since the a and b columns have conflicting implicit collations. Since the < operator does need to know which collation to use, this will result in an error. The error can be resolved by attaching an explicit collation specifier to either input expression, thus:

\n
SELECT a < b COLLATE \"de_DE\" FROM test1;\n
\n

or equivalently

\n
SELECT a COLLATE \"de_DE\" < b FROM test1;\n
\n

On the other hand, the structurally similar case

\n
SELECT a || b FROM test1;\n
\n

does not result in an error, because the || operator does not care about collations: its result is the same regardless of the collation.

\n

The collation assigned to a function or operator's combined input expressions is also considered to apply to the function or operator's result, if the function or operator delivers a result of a collatable data type. So, in

\n
SELECT * FROM test1 ORDER BY a || 'foo';\n
\n

the ordering will be done according to de_DE rules. But this query:

\n
SELECT * FROM test1 ORDER BY a || b;\n
\n

results in an error, because even though the || operator doesn't need to know a collation, the ORDER BY clause does. As before, the conflict can be resolved with an explicit collation specifier:

\n
SELECT * FROM test1 ORDER BY a || b COLLATE \"fr_FR\";\n
\n
", "manual_path": "/docs/18/collation.html#COLLATION-CONCEPTS", "comparison_data": {"scope": "Source provider identity; installation/build availability is separate", "provider": "builtin", "catalog_code": "b"}, "comparison_hash": "d0ee87b3545cc68aafaa491d16e6d3a73ddc2ded39dd20ba234b922cd06fd397"}, "comparison": {"left": "17", "right": "18", "status": "unchanged", "diff": ""}}