# 8.14.JSON类型

8.14.1. JSON输入和输出语法

8.14.2. 设计JSON文档

8.14.3.jsonb遏制与生存

8.14.4.jsonb索引

8.14.5.jsonb订阅

8.14.6. 转变

8.14.7. jsonpath类型

JSON数据类型用于存储JSON(JavaScript对象表示法)数据,如中所述RFC 7159 (opens new window)。这些数据也可以存储为文本,但JSON数据类型的优点是,根据JSON规则,每个存储的值都是有效的。对于存储在这些数据类型中的数据,还可以使用各种特定于JSON的函数和运算符;看见第9.16节.

PostgreSQL提供了两种存储JSON数据的类型:jsonjsonb。为了实现这些数据类型的高效查询机制,PostgreSQL还提供jsonpath中描述的数据类型第8.14.7节.

这个jsonjsonb数据类型接受几乎相同的值集作为输入。主要的实际区别在于效率。这个json数据类型存储输入文本的精确副本,处理函数必须在每次执行时重新分析;虽然jsonb数据以分解的二进制格式存储,由于增加了转换开销,输入速度稍慢,但处理速度明显加快,因为不需要重新分析。jsonb还支持索引,这可能是一个显著的优势。

因为json类型存储输入文本的精确副本,它将保留标记之间语义上无关紧要的空白,以及JSON对象中键的顺序。此外,如果值中的JSON对象多次包含同一个键,则保留所有键/值对。(处理函数将最后一个值视为操作值。)相比之下jsonb不保留空白,不保留对象关键帧的顺序,也不保留重复的对象关键帧。如果在输入中指定了重复键,则只保留最后一个值。

一般来说,大多数应用程序应该更喜欢将JSON数据存储为jsonb,除非有非常特殊的需求,例如关于对象键顺序的遗留假设。

RFC 7159指定JSON字符串应该用UTF8编码。因此,除非数据库编码为UTF8,否则JSON类型不可能严格符合JSON规范。尝试直接包含数据库编码中无法表示的字符将失败;相反,可以在数据库编码中表示但不能在UTF8中表示的字符将被允许。

RFC 7159允许JSON字符串包含由\u*XXXX*.在json类型,不管数据库编码如何,都允许Unicode转义,并且只检查语法正确性(即,后面跟着四个十六进制数字)\u).但是jsonb更严格的是:它不允许对数据库编码中无法表示的字符进行Unicode转义。这个jsonb类型也拒绝\u0000(因为PostgreSQL的文本它坚持使用Unicode代理对来指定Unicode基本多语言平面之外的字符是正确的。将有效的Unicode转义转换为等效的单个字符进行存储;这包括将代理项对折叠为单个字符。

# 笔记

中描述的许多JSON处理函数第9.16节将Unicode转义转换为常规字符,因此将抛出与刚才描述的相同类型的错误,即使它们的输入是jsonjsonb.事实上json输入函数不进行这些检查可能会被视为历史工件,尽管它允许在不支持所表示字符的数据库编码中简单存储(无需处理)JSON Unicode转义。

将文本JSON输入转换为jsonb,RFC 7159描述的基元类型有效地映射到本机PostgreSQL类型,如中所示表8.23.因此,对于什么是有效的,还有一些小的额外限制jsonb不适用于json类型,也不是抽象的JSON,对应于底层数据类型所能表示的内容的限制。尤其是jsonb将拒绝超出PostgreSQL范围的数字数字的数据类型,而json不会的。RFC 7159允许此类实施定义的限制。然而,在实践中,这种问题更可能发生在其他实现中,因为表示JSON的数字基本类型为IEEE 754双精度浮点(RFC 7159明确预期并允许)。当使用JSON作为此类系统的交换格式时,应考虑与PostgreSQL最初存储的数据相比,丢失数字精度的危险。

相反,如表中所述,JSON基元类型的输入格式存在一些小限制,这些限制不适用于相应的PostgreSQL类型。

表8.23.JSON基元类型和相应的PostgreSQL类型

JSON基元类型 PostgreSQL类型 笔记
一串 文本 \u0000是不允许的,因为Unicode转义表示数据库编码中不可用的字符
数字 数字的 无穷价值观是不允许的
布尔值 布尔值 只有小写字母符合事实的错误的拼写是可以接受的
无效的 (无) SQL 无效的这是一个不同的概念

# 8.14.1.JSON输入和输出语法

JSON数据类型的输入/输出语法如RFC 7159所述。

以下都是有效的json(或jsonb)表达方式:

-- Simple scalar/primitive value
-- Primitive values can be numbers, quoted strings, true, false, or null
SELECT '5'::json;

-- Array of zero or more elements (elements need not be of same type)
SELECT '[1, 2, "foo", null]'::json;

-- Object containing pairs of keys and values
-- Note that object keys must always be quoted strings
SELECT '{"bar": "baz", "balance": 7.77, "active": false}'::json;

-- Arrays and objects can be nested arbitrarily
SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json;

如前所述,当输入一个JSON值,然后在没有任何额外处理的情况下打印时,json输出与输入相同的文本,而jsonb不会保留语义上无关紧要的细节,例如空格。例如,请注意此处的差异:

SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::json;
                      json                       
### 8.14.2. Designing JSON Documents

 Representing data as JSON can be considerably more flexible than the traditional relational data model, which is compelling in environments where requirements are fluid. It is quite possible for both approaches to co-exist and complement each other within the same application. However, even for applications where maximal flexibility is desired, it is still recommended that JSON documents have a somewhat fixed structure. The structure is typically unenforced (though enforcing some business rules declaratively is possible), but having a predictable structure makes it easier to write queries that usefully summarize a set of “documents” (datums) in a table.

 JSON data is subject to the same concurrency-control considerations as any other data type when stored in a table. Although storing large documents is practicable, keep in mind that any update acquires a row-level lock on the whole row. Consider limiting JSON documents to a manageable size in order to decrease lock contention among updating transactions. Ideally, JSON documents should each represent an atomic datum that business rules dictate cannot reasonably be further subdivided into smaller datums that could be modified independently.

### 8.14.3. `jsonb` Containment and Existence

[]()[]()

 Testing *containment* is an important capability of `jsonb`. There is no parallel set of facilities for the `json` type. Containment tests whether one `jsonb` document has contained within it another one. These examples return true except as noted:

--简单的标量/基元值只包含相同的值:选择“foo”::jsonb@>“foo”::jsonb;

--右边的数组包含在左边的数组中:SELECT'[1, 2, 3]“::jsonb@>”[1, 3]“::jsonb;

--数组元素的顺序不重要,所以这也是正确的:SELECT'[1, 2, 3]“::jsonb@>”[3, 1]“::jsonb;

--重复的数组元素也无关紧要:选择'[1, 2, 3]“::jsonb@>”[1, 2, 2]“::jsonb;

--右边只有一对的对象被包含在左边的对象中:选择“{”product:“PostgreSQL”,“version”:9.4,“jsonb”:true}::jsonb@>“{”version:9.4}::jsonb;

--右侧的数组被认为不包含在左侧的--数组中,即使其中嵌套了一个类似的数组:SELECT'[1,2,[1, 3]]“::jsonb@>”[1, 3]“::jsonb;——结果是错误的

--但它包含一层嵌套:选择“[1,2,[1, 3]]“::jsonb@>”[[1, 3]]“::jsonb;

--同样,这里也不报告包含:选择“{foo”:{bar:“baz”}}”::jsonb@>“{bar:“baz”}”::jsonb;——结果是错误的

--包含一个顶级键和一个空对象:选择“{”foo:{”bar:“baz”}}”::jsonb@>“{”foo:{}}”::jsonb;

 The general principle is that the contained object must match the containing object as to structure and data contents, possibly after discarding some non-matching array elements or object key/value pairs from the containing object. But remember that the order of array elements is not significant when doing a containment match, and duplicate array elements are effectively considered only once.

 As a special exception to the general principle that the structures must match, an array may contain a primitive value:

--此数组包含基本字符串值:SELECT'[“foo”,“bar”"]“::jsonb@>“bar”::jsonb;

--此异常不是相互的——此处报告非包容:选择“bar”::jsonb@>'[“酒吧”"]“::jsonb;——结果是错误的

`jsonb` also has an *existence* operator, which is a variation on the theme of containment: it tests whether a string (given as a `text` value) appears as an object key or array element at the top level of the `jsonb` value. These examples return true except as noted:

--字符串作为数组元素存在:选择'[“foo”、“bar”、“baz”"]“::jsonb?”酒吧;

--字符串作为对象键存在:选择“{”foo:“bar”}”::jsonb?“福;

--不考虑对象值:选择“{”foo:“bar”}”::jsonb?“酒吧;——结果是错误的

--与包含一样,存在必须在顶层匹配:选择“{”foo:{”bar:“baz”}”::jsonb?“酒吧;——结果是错误的

--如果字符串与原始JSON字符串匹配,则认为该字符串存在:选择“foo”::jsonb福;

 JSON objects are better suited than arrays for testing containment or existence when there are many keys or elements involved, because unlike arrays they are internally optimized for searching, and do not need to be searched linearly.

### Tip

 Because JSON containment is nested, an appropriate query can skip explicit selection of sub-objects. As an example, suppose that we have a `doc` column containing objects at the top level, with most objects containing `tags` fields that contain arrays of sub-objects. This query finds entries in which sub-objects containing both `"term":"paris"` and `"term":"food"` appear, while ignoring any such keys outside the `tags` array:

从doc@>{“标签”所在的网站中选择doc->“site_name”:[{"“术语”:“巴黎”":","},“术语”:“食物”{"]}';

 One could accomplish the same thing with, say,

从文档->'tags'@>'[{"“术语”:“巴黎”":","},“术语”:“食物”{"]';

 but that approach is less flexible, and often less efficient as well.

 On the other hand, the JSON existence operator is not nested: it will only look for the specified key or array element at top level of the JSON value.

 The various containment and existence operators, along with all other JSON operators and functions are documented in [Section 9.16](functions-json.html).

### 8.14.4. `jsonb` Indexing

[]()

 GIN indexes can be used to efficiently search for keys or key/value pairs occurring within a large number of `jsonb` documents (datums). Two GIN “operator classes” are provided, offering different performance and flexibility trade-offs.

 The default GIN operator class for `jsonb` supports queries with top-level key-exists operators `?`, `?&` and `?|` operators and path/value-exists operator `@>`. (For details of the semantics that these operators implement, see [Table 9.45](functions-json.html#FUNCTIONS-JSONB-OP-TABLE).) An example of creating an index with this operator class is:

使用GIN(jdoc)在api上创建索引idxgin;

 The non-default GIN operator class `jsonb_path_ops` supports indexing the `@>` operator only. An example of creating an index with this operator class is:

使用GIN(jdoc jsonb_path_ops)在api上创建索引idxginp;

 Consider the example of a table that stores JSON documents retrieved from a third-party web service, with a documented schema definition. A typical document is:

{“guid”:“9c36adc1-7fb5-4d5b-83b4-90356a46061a”,“姓名”:“安吉拉·巴顿”,“活跃”:真,“公司”:“麦格纳丰”,“地址”:“178霍华德广场,华盛顿海湾,702”,“注册”:“2009-11-07T08:53:22+08:00”,“纬度”:19.793713,“经度”:86.513373,“标签”:[“enim”、“aliquip”、“qui”"] }

 We store these documents in a table named `api`, in a `jsonb` column named `jdoc`. If a GIN index is created on this column, queries like the following can make use of the index:

--查找键“company”的值为“Magnafone”的文档,从jdoc@>“{”company:“Magnafone”}”的api中选择jdoc->'guid',jdoc->'name';

 However, the index could not be used for queries like the following, because though the operator `?` is indexable, it is not applied directly to the indexed column `jdoc`:

--查找键“tags”包含键或数组元素“qui”的文档,从jdoc->“tags”的api中选择jdoc->“guid”,jdoc->“name”魁;

 Still, with appropriate use of expression indexes, the above query can use an index. If querying for particular items within the `"tags"` key is common, defining an index like this may be worthwhile:

使用GIN((jdoc->“tags”)在api上创建索引idxgintags;

 Now, the `WHERE` clause `jdoc -> 'tags' ? 'qui'` will be recognized as an application of the indexable operator `?` to the indexed expression `jdoc -> 'tags'`. (More information on expression indexes can be found in [Section 11.7](indexes-expressional.html).)

 Also, GIN index supports `@@` and `@?` operators, which perform `jsonpath` matching.

从jdoc@'$所在的api中选择jdoc->“guid”,jdoc->“name”。标签[*]"魁";;


从jdoc@?'$所在的api中选择jdoc->“guid”,jdoc->“name”。标签[*]? (@==“qui”);

 GIN index extracts statements of following form out of `jsonpath`: *`accessors_chain`* = *`const`*. Accessors chain may consist of `.key`, `[*]`, and `[*`index`*]` accessors. `jsonb_ops` additionally supports `.*` and `.**` accessors.

 Another approach to querying is to exploit containment, for example:

--查找键“tags”包含数组元素“qui”的文档,从jdoc@>'{“tags”所在的api中选择jdoc->'guid',jdoc->'name”:[“魁”"]}';

 A simple GIN index on the `jdoc` column can support this query. But note that such an index will store copies of every key and value in the `jdoc` column, whereas the expression index of the previous example stores only data found under the `tags` key. While the simple-index approach is far more flexible (since it supports queries about any key), targeted expression indexes are likely to be smaller and faster to search than a simple index.

 Although the `jsonb_path_ops` operator class supports only queries with the `@>`, `@@` and `@?` operators, it has notable performance advantages over the default operator class `jsonb_ops`. A `jsonb_path_ops` index is usually much smaller than a `jsonb_ops` index over the same data, and the specificity of searches is better, particularly when queries contain keys that appear frequently in the data. Therefore search operations typically perform better than with the default operator class.

 The technical difference between a `jsonb_ops` and a `jsonb_path_ops` GIN index is that the former creates independent index items for each key and value in the data, while the latter creates index items only for each value in the data. [<sup class="footnote" id="id-1.5.7.22.18.9.3">[7]</sup>](#ftn.id-1.5.7.22.18.9.3) Basically, each `jsonb_path_ops` index item is a hash of the value and the key(s) leading to it; for example to index `{"foo": {"bar": "baz"}}`, a single index item would be created incorporating all three of `foo`, `bar`, and `baz` into the hash value. Thus a containment query looking for this structure would result in an extremely specific index search; but there is no way at all to find out whether `foo` appears as a key. On the other hand, a `jsonb_ops` index would create three index items representing `foo`, `bar`, and `baz` separately; then to do the containment query, it would look for rows containing all three of these items. While GIN indexes can perform such an AND search fairly efficiently, it will still be less specific and slower than the equivalent `jsonb_path_ops` search, especially if there are a very large number of rows containing any single one of the three index items.

 A disadvantage of the `jsonb_path_ops` approach is that it produces no index entries for JSON structures not containing any values, such as `{"a": {}}`. If a search for documents containing such a structure is requested, it will require a full-index scan, which is quite slow. `jsonb_path_ops` is therefore ill-suited for applications that often perform such searches.

`jsonb` also supports `btree` and `hash` indexes. These are usually useful only if it's important to check equality of complete JSON documents. The `btree` ordering for `jsonb` datums is seldom of great interest, but for completeness it is:

对象>数组>布尔值>数字>字符串>空值

n对对象>n-1对对象

包含n个元素的数组>包含n-1个元素的数组

 Objects with equal numbers of pairs are compared in the order:

键1,值1,键2.。。

 Note that object keys are compared in their storage order; in particular, since shorter keys are stored before longer keys, this can lead to results that might be unintuitive, such as:

{aa:1,c:1}>{b:1,d:1}

 Similarly, arrays with equal numbers of elements are compared in the order:

元素1,元素2.。。

 Primitive JSON values are compared using the same comparison rules as for the underlying PostgreSQL data type. Strings are compared using the default database collation.

### 8.14.5. `jsonb` Subscripting

 The `jsonb` data type supports array-style subscripting expressions to extract and modify elements. Nested values can be indicated by chaining subscripting expressions, following the same rules as the `path` argument in the `jsonb_set` function. If a `jsonb` value is an array, numeric subscripts start at zero, and negative integers count backwards from the last element of the array. Slice expressions are not supported. The result of a subscripting expression is always of the jsonb data type.

`UPDATE` statements may use subscripting in the `SET` clause to modify `jsonb` values. Subscript paths must be traversable for all affected values insofar as they exist. For instance, the path `val['a']['b']['c']` can be traversed all the way to `c` if every `val`, `val['a']`, and `val['a']['b']` is an object. If any `val['a']` or `val['a']['b']` is not defined, it will be created as an empty object and filled as necessary. However, if any `val` itself or one of the intermediary values is defined as a non-object such as a string, number, or `jsonb` `null`, traversal cannot proceed so an error is raised and the transaction aborted.

 An example of subscripting syntax:

--按键选择提取对象值(“{a:1}”::jsonb)[“a”'];

--通过键路径选择(“{a”:{b”:{“c”:1}}}’::jsonb)提取嵌套对象值[“a”]['b'][“c”'];

--按索引提取数组元素[1,“2”,空,]'::jsonb)

[1];

--按键更新对象值。请注意“1”周围的引号:赋值的--value必须是jsonb类型以及UPDATE table_name SET jsonb_字段[“钥匙”'] = '1';

--如果任何记录的jsonb_字段[“a”]['b']是某种东西,而不是物体。例如,值{“a”:1}有一个数字值,即键“a”的值。更新表格名称集jsonb_字段[“a”]['b'][“c”'] = '1';

--使用带有订阅的WHERE子句筛选记录。因为--subscripting的结果是jsonb,所以我们将其与之进行比较的值也必须是jsonb。-双引号使“value”也是一个有效的jsonb字符串。从jsonb_字段所在的表_name中选择*[“钥匙”']='值';

`jsonb` assignment via subscripting handles a few edge cases differently from `jsonb_set`. When a source `jsonb` value is `NULL`, assignment via subscripting will proceed as if it was an empty JSON value of the type (object or array) implied by the subscript key:

--在jsonb_字段为空的地方,它现在是{“a”:1}更新表_名称集jsonb_字段[“a”'] = '1';

--jsonb_字段为空时,现在为空[1]更新表格名称集jsonb_字段[0] = '1';

 If an index is specified for an array containing too few elements, `NULL` elements will be appended until the index is reachable and the value can be set.

--jsonb_field的位置是[],现在是[空,空,2,]; -- jsonb_field在哪里[0]现在是[0,空,2,]更新表格名称集jsonb_字段[2] = '2';

 A `jsonb` value will accept assignments to nonexistent subscript paths as long as the last existing element to be traversed is an object or array, as implied by the corresponding subscript (the element indicated by the last subscript in the path is not traversed and may be anything). Nested array and object structures will be created, and in the former case `null`-padded, as specified by the subscript path until the assigned value can be placed.

--jsonb_字段所在的位置是{},现在是{'a':[{'b'::1}]}更新表格名称集jsonb_字段[“a”][0][“b”'] = '1';

--jsonb_field的位置是[],现在是[null,,a{':1':]更新表格名称集jsonb_字段[1.]['a'] = '1';

### 8.14.6. Transforms

 Additional extensions are available that implement transforms for the `jsonb` type for different procedural languages.

 The extensions for PL/Perl are called `jsonb_plperl` and `jsonb_plperlu`. If you use them, `jsonb` values are mapped to Perl arrays, hashes, and scalars, as appropriate.

 The extensions for PL/Python are called `jsonb_plpythonu`, `jsonb_plpython2u`, and `jsonb_plpython3u` (see [Section 46.1](plpython-python23.html) for the PL/Python naming convention). If you use them, `jsonb` values are mapped to Python dictionaries, lists, and scalars, as appropriate.

 Of these extensions, `jsonb_plperl` is considered “trusted”, that is, it can be installed by non-superusers who have `CREATE` privilege on the current database. The rest require superuser privilege to install.

### 8.14.7. jsonpath Type

[]()

 The `jsonpath` type implements support for the SQL/JSON path language in PostgreSQL to efficiently query JSON data. It provides a binary representation of the parsed SQL/JSON path expression that specifies the items to be retrieved by the path engine from the JSON data for further processing with the SQL/JSON query functions.

 The semantics of SQL/JSON path predicates and operators generally follow SQL. At the same time, to provide a natural way of working with JSON data, SQL/JSON path syntax uses some JavaScript conventions:

* Dot (`.`) is used for member access.

* Square brackets (`[]`) are used for array access.

* SQL/JSON arrays are 0-relative, unlike regular SQL arrays that start from 1.

 An SQL/JSON path expression is typically written in an SQL query as an SQL character string literal, so it must be enclosed in single quotes, and any single quotes desired within the value must be doubled (see [Section 4.1.2.1](sql-syntax-lexical.html#SQL-SYNTAX-STRINGS)). Some forms of path expressions require string literals within them. These embedded string literals follow JavaScript/ECMAScript conventions: they must be surrounded by double quotes, and backslash escapes may be used within them to represent otherwise-hard-to-type characters. In particular, the way to write a double quote within an embedded string literal is `\"`, and to write a backslash itself, you must write `\\`. Other special backslash sequences include those recognized in JSON strings: `\b`, `\f`, `\n`, `\r`, `\t`, `\v` for various ASCII control characters, and `\u*`NNNN`*` for a Unicode character identified by its 4-hex-digit code point. The backslash syntax also includes two cases not allowed by JSON: `\x*`NN`*` for a character code written with only two hex digits, and `\u{*`N...`*}` for a character code written with 1 to 6 hex digits.

 A path expression consists of a sequence of path elements, which can be any of the following:

* Path literals of JSON primitive types: Unicode text, numeric, true, false, or null.

* Path variables listed in [Table 8.24](datatype-json.html#TYPE-JSONPATH-VARIABLES).

* Accessor operators listed in [Table 8.25](datatype-json.html#TYPE-JSONPATH-ACCESSORS).

* `jsonpath` operators and methods listed in [Section 9.16.2.2](functions-json.html#FUNCTIONS-SQLJSON-PATH-OPERATORS).

* Parentheses, which can be used to provide filter expressions or define the order of path evaluation.

 For details on using `jsonpath` expressions with SQL/JSON query functions, see [Section 9.16.2](functions-json.html#FUNCTIONS-SQLJSON-PATH).

**Table 8.24. `jsonpath` Variables**

| Variable |                                                                                       Description                                                                                        |
|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|   `$`    |                                                        A variable representing the JSON value being queried (the *context item*).                                                        |
|`$varname`| A named variable. Its value can be set by the parameter *`vars`* of several JSON processing functions; see [Table 9.47](functions-json.html#FUNCTIONS-JSON-PROCESSING-TABLE) for details.|
|   `@`    |                                                       A variable representing the result of path evaluation in filter expressions.                                                       |

**Table 8.25. `jsonpath` Accessors**

|                        Accessor Operator                        |                                                                                                                                                                                                                                                                                                                                    Description                                                                                                                                                                                                                                                                                                                                     |
|-----------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|              `.*`key`*`<br/><br/>`."$*`varname`*"`              |                                                                                                                                                                                                           Member accessor that returns an object member with the specified key. If the key name matches some named variable starting with `$` or does not meet the JavaScript rules for an identifier, it must be enclosed in double quotes to make it a string literal.                                                                                                                                                                                                           |
|                              `.*`                               |                                                                                                                                                                                                                                                                                   Wildcard member accessor that returns the values of all members located at the top level of the current object.                                                                                                                                                                                                                                                                                  |
|                              `.**`                              |                                                                                                                                                                                                                       Recursive wildcard member accessor that processes all levels of the JSON hierarchy of the current object and returns all the member values, regardless of their nesting level. This is a PostgreSQL extension of the SQL/JSON standard.                                                                                                                                                                                                                      |
|`.**{*`level`*}`<br/><br/>`.**{*`start_level`* to *`end_level`*}`|                                                                                                                                                                                            Like `.**`, but selects only the specified levels of the JSON hierarchy. Nesting levels are specified as integers. Level zero corresponds to the current object. To access the lowest nesting level, you can use the `last` keyword. This is a PostgreSQL extension of the SQL/JSON standard.                                                                                                                                                                                           |
|                     `[*`subscript`*, ...]`                      | Array element accessor. `*`subscript`*` can be given in two forms: `*`index`*` or `*`start_index`* to *`end_index`*`. The first form returns a single array element by its index. The second form returns an array slice by the range of indexes, including the elements that correspond to the provided *`start_index`* and *`end_index`*.<br/><br/> The specified *`index`* can be an integer, as well as an expression returning a single numeric value, which is automatically cast to integer. Index zero corresponds to the first array element. You can also use the `last` keyword to denote the last array element, which is useful for handling arrays of unknown length.|
|                              `[*]`                              |                                                                                                                                                                                                                                                                                                          Wildcard array element accessor that returns all array elements.                                                                                                                                                                                                                                                                                                          |