Project: YugabyteDB (App Definition and Development / Database)
File: jsonb-object.md

title: jsonbobject() and jsonobject() [JSON] headerTitle: jsonbobject() and jsonobject() linkTitle: jsonb_object() description: Create a JSON object from SQL arrays that specify keys with their values of SQL data type text. menu: v2.18: identifier: jsonb-object parent: json-functions-operators weight: 150 type: docs Purpose: Create a JSON object from SQL arrays that specify keys with their values of SQL data type `text`. Signature For the `jsonb` variant: ``` input value: ] | [ text[], text[] ] return value: jsonb ``` Notes: The `jsonb_object()` function achieves a similar effect to but with significantly less verbose syntax. Precisely because you present a single `text` actual, you can avoid the fuss of dynamic invocation and of dealing with interior single quotes that this brings in its train. However, it has the limitation that the primitive values in the resulting JSON value can only be string. It has three overloads. The first overload has a single `text[]` formal whose actual text expresses the variadic intention conventionally: the alternating comma separated items are the respectively the key and the value of a key-value pair. ```plpgsql do $body$ declare array_values constant text[] := array['a', '17', 'b', $$'Hello', you$$, 'c', 'true']; j constant jsonb := jsonbobject(arrayvalues); expected_j constant jsonb := $${"a": "17", "b": "'Hello', you", "c": "true"}$$; begin assert j = expected_j, 'unexpected'; end; $body$; ``` Compare this result with the result from supplying the same primitive SQL values to the function. There, the data types of the SQL values are properly honored: The numeric `17` and the boolean `TRUE` are represented by the proper JSON primitive types. But with `jsonbobject()` it is not possible to express that `17` should be taken as a JSON number value and `TRUE` should be taken as a JSON boolean_ value. The potential loss of data type fidelity brought by `jsonbobject()` is a high price to pay for the reduction in verbosity. On the other hand, `jsonbobject()` has the distinct advantage over `jsonbbuildobject()` that you don't need to know statically how many key-value pairs the target JSON object is to have. If you think that it improves the clarity, you can use the second overload. This has a single `text` formalin other words an array of arrays. ```plpgsql do $body$ declare array_values constant text := array[ array['a', '17'], array['b', $$'Hello', you$$], array['c', 'true'] ]; j constant jsonb := jsonbobject(arrayvalues); expected_j constant jsonb := $${"a": "17", "b": "'Hello', you", "c": "true"}$$; begin assert j = expected_j, 'unexpected'; end; $body$; ``` This produces the identical result to that produced by the example for the first overload. Again, if you think that it improves the clarity, you can use the third overload. This has a two `text[]` formals. The first expresses the list keys of the key-values pairs. And the second expresses the list values of the key-values pairs. The items must correspond pairwise, and clearly each array must have the same number of items. For example: ```plpgsql do $body$ declare array_keys constant text[] := array['a', 'b', 'c' ]; array_values constant text[] := array['17', $$'Hello', you$$, 'true']; j constant jsonb := jsonbobject(arraykeys, array_values); expected_j constant jsonb := $${"a": "17", "b": "'Hello', you", "c": "true"}$$; begin assert j = expected_j, 'unexpected'; end; $body$; ``` This, too, produces the identical result to that produced by the example for the first overload.