Universally Unique Identifier (UUID) Types
This data type stores universally unique identifiers defined by RFC 4122, ISO/IEF 9834-8:2005 and related standards. This identifier is a 128-bit quantity that is generated by an algorithm chosen to make it very unlikely that the same identifier will be generated by anyone else in the known universe using the same algorithm.
A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing the 128 bits. An example of a UUID in this standard form is:
a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
openGauss also accepts the following alternative forms for input: use of upper-case letters and digits, standard format surrounded by braces, omitting some or all hyphens, and adding a hyphen after any group of four digits. Example:
A0EEBC99-9C0B-4EF8-BB6D-6BB9BD380A11
{a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11}
a0eebc999c0b4ef8bb6d6bb9bd380a11
a0ee-bc99-9c0b-4ef8-bb6d-6bb9-bd38-0a11
Output is always in the standard form.
JSON/JSONB Types
JavaScript Object Notation (JSON) data can be a single scalar, an array, or a key-value pair object. The array and object can be called a container:
·Scalar: a number, Boolean, string, or null
·Array: defined in a pair of square brackets ([]), in which elements can be any type of JSON data, and are not necessarily of the same type.
·Object: defined in a pair of braces ({}), in which objects are stored in the format of key:value. Each key must be a string enclosed by a pair of double quotation marks (""), and its value can be any type of JSON data. In case of duplicate keys, the last key-value pair will be used.
openGauss supports two types JSON and JSONB to store JSON data. JSON is a complete copy of the entered character string and is parsed when used. The entered spaces, duplicate keys, and sequence are retained. JSONB parses the input binary data. During parsing, JSONB deletes semantic-irrelevant details and duplicate keys, and sorts key-values. Therefore, JSONB does not need to parse the binary data again when it is used.
So you can see that both JSON and JSONB are of JSON data type, and the same strings can be entered as input. The main difference between JSON and JSONB is the efficiency. Because JSON data is an exact copy of the input text, the data must be parsed on every execution; in contrast, JSONB data is stored in a decomposed binary form and can be processed faster, though this makes it slightly slower in input due to the conversion mechanism. In addition, because the JSONB data form is unified, it better supports more powerful functions, for example, comparing sizes according to a specific rule. JSONB also supports indexing, which is a significant advantage.
·Input format
An input must be a JSON-compliant string, which is enclosed in single quotation marks ('').
Null (null-json): Only null is supported, and all letters are in lowercase.
Number (num-json): The value can be a positive or negative integer, decimal fraction, or 0. The scientific notation is supported.
Boolean (bool-json): The value can only be true or false in lowercase.
String (str-json): The value must be a string enclosed in double quotation marks ("").
Array (array-json): Arrays are enclosed in square brackets ([]). Elements in the array can be any valid JSON data, and are unnecessarily of the same type.
Object (object-json): The value is enclosed in braces ({}). The key must be a JSON-compliant string, and the value can be any valid JSON string.
·JSONB advanced features
·Precautions
·It does not support row-store tables.
·It cannot be used as a partition key.
·It does not support foreign tables and MOTs.
The main difference between JSON and JSONB lies in the storage mode. JSONB stores parsed binary data, which reflects the JSON hierarchy and facilitates direct access. Therefore, JSONB has many advanced features that JSON does not have.
·Format normalization
·After the input object-json string is parsed into JSONB binary data, semantically irrelevant details are naturally discarded, for example, spaces.
·For object-json, duplicate key-values are deleted and only the last key-value is retained. For example:
·For object-json, key-values will be re-sorted. The sorting rule is as follows: 1. Longer key-values are sorted last. 2. If the key-values are of the same length, the key-values with a larger ASCII code are sorted after the key-values with a smaller ASCII code:
·Size comparison
Format normalization ensures that only one form of JSONB data exists in the same semantics. Therefore, sizes may be compared according to a specific rule.
·First, compare the types: object-jsonb > array-jsonb > bool-jsonb > num-jsonb > str-jsonb > null-jsonb.
·Compare the content if data types are the same:
·str-json: The default text sorting rule of the database is used for comparison. A positive value indicates greater than, a negative value indicates less than, and 0 indicates equal.
·num-json: numeric comparison
·bool-json: true > false
·array-jsonb: long elements > short elements. If the lengths are the same, compare each element in sequence.
·object-jsonb: If the length of a key-value pair is longer than that of a short key-value pair, the key is compared first, and then the value is compared.
·Creating indexes, primary keys, and foreign keys
·B-tree index
B-tree indexes, primary keys, and foreign keys can be created for the JSONB type.
·GIN index
GIN indexes can be used to effectively search for keys or key-value pairs that appear in a large number of JSONB documents (datums). Two GIN operator classes (jsonb_ops and jsonb_hash_ops) are provided for different performance and flexibility choices. The default GIN operator class supports @>, <@, ?, ?& and ?| operator query. The non-default GIN operator class jsonb_path_ops supports only the @> and <@ operators.
·Containment and existence
Querying whether a JSON contains some elements or whether some elements exist in a JSON is an important capability of JSONB.
Top comments (0)