anchor.diff:  |`io.debezium.data.Json`
   | Example: output representation using the JSON converter is `{\"key\" : \"val\"}`
   
  -|===
  -
  -When `hstore.handling.mode` configuration property is set to `map`, then the connector will use the `MAP` schema type for all `HSTORE` columns.
  -
  -[cols="15%a,15%a,35%a,35%a"]
  +|`HSTORE`
  +|`MAP`
  +|
  +| Example: output representation  using the JSON converter is `{"key" : "val"}`
  +
  +|===
  +
  +[id="postgresql-domain-types"]
  +=== Domain types
  +
  +PostgreSQL supports user-defined types that are based on other underlying types. When such column types are used, {prodname} exposes the column's representation based on the full type hierarchy.
  +
  +[IMPORTANT]
  +====
  +Capturing changes in columns that use PostgreSQL domain types requires special consideration. When a column is defined to contain a domain type that extends one of the default database types and the domain type defines a custom length or scale, the generated schema inherits that defined length or scale.
  +
  +When a column is defined to contain a domain type that extends another domain type that defines a custom length or scale, the generated schema does *not* inherit the defined length oe scale because of the PostgreSQL driver's column metadata implementation.
  +====
  +
  +[id="postgresql-network-address-types"]
  +=== Network address types
  +
  +PostgreSQL haddata types that can store IPv4, IPv6, and MAC addresses. It is better to use these types instead of plain text types to store network addresses. Network address types offer input error checking and specialized operators and functions.
  +
  +.Mappings for network address types
  +[cols="15%a,15%a,35%a,35%a",options="header"]
   |===
   |PostgreSQL Data Type
   |Literal type (schema type)
   |Semantic type (schema name)
   |Notes
   
  -|`HSTORE`
  -|`MAP`
  -|
  -| Example: output representation  using the JSON converter is `{"key" : "val"}`
  -
  -|===
  -
  -// Type: concept
  -// ModuleID: how-debezium-maps-postgresql-domain-types
  -// Title: How {prodname} maps PostgreSQL domain types
  -[[postgresql-domain-types]]
  -=== PostgreSQL domain types
  -
  -PostgreSQL also supports the notion of user-defined types that are based upon other underlying types.
  -When such column types are used, {prodname} exposes the column's representation based on the full type hierarchy.
  -
  -[IMPORTANT]
  -====
  -Special consideration should be taken when monitoring columns that use domain types.
  -
  -When a column is defined using a domain type that extends one of the default database types and the domain type defines a custom length/scale, the generated schema will inherit that defined length/scale.
  -
  -When a column is defined using a domain type that extends another domain type that defines a custom length/scale, the generated schema will **not** inherit the defined length/scale because the PostgreSQL driver's column metadata implementation.
  -====
  -
  -// Type: concept
  -// ModuleID: how-debezium-maps-postgresql-network-address-types
  -// Title: How {prodname} maps PostgreSQL network address types
  -[[postgresql-network-address-types]]
  -=== Network address types
  -
  -PostgreSQL also have data types that can store IPv4, IPv6, and MAC addresses. It is better to use these instead of plain text types to store network addresses, because these types offer input error checking and specialized operators and functions.
  -
  -[cols="15%a,15%a,35%a,35%a"]
  -|===
  -|PostgreSQL Data Type
  -|Literal type (schema type)
  -|Semantic type (schema name)
  -|Notes
  -
   |`INET`
   |`STRING`
   |
  
positive.code: |===
  
  There is an exception to this rule.
  When the `NUMERIC` or `DECIMAL` types are used without any scale constraints then it means that the values coming from the database have a different (variable) scale for each value.
  In this case a type `io.debezium.data.VariableScaleDecimal` is used and it contains both value and scale of the transferred value.
  
  [cols="15%a,15%a,35%a,35%a"]
  |===
  |PostgreSQL Data Type
  |Literal type (schema type)
  
negative.code: The connector relies on and reflects the PostgreSQL logical decoding feature, which has the following limitations:
  
  * Logical decoding does not support DDL changes. This means that the connector is unable to report DDL change events back to consumers.
  * Logical decoding replication slots are supported on only `primary` servers. When there is a cluster of PostgreSQL servers, the connector can run on only the active `primary` server. It cannot run on `hot` or `warm` standby replicas. If the `primary` server fails or is demoted, the connector stops. After the `primary` server has recovered, you can restart the connector. If a different PostgreSQL server has been promoted to `primary`, adjust the connector configuration before restarting the connector. 
  
  {link-prefix}:{link-postgresql-connector}#postgresql-when-things-go-wrong[ Behavior when things go wrong] describes what the connector does when there is a problem. 
  ====
  
  [IMPORTANT]
  ====
  {prodname} currently supports databases with UTF-8 character encoding only.
  With a single byte character encoding, it is not possible to correctly process strings that contain extended ASCII code characters.
  ====
  
  // Type: assembly
  