public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v49 3/3] Replace assuming a composite object on a scalar
4+ messages / 4 participants
[nested] [flat]
* [PATCH v49 3/3] Replace assuming a composite object on a scalar
@ 2021-01-20 15:53 Dmitrii Dolgov <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Dmitrii Dolgov @ 2021-01-20 15:53 UTC (permalink / raw)
For jsonb subscripting assignment it could happen that the provided path
assumes an object or an array at some level, but the source jsonb has a
scalar value there. Originally the update operation will be skipped and
no message will be shown that nothing happened. Return an error to
indicate such situations.
---
doc/src/sgml/json.sgml | 39 +++++++++++++++++++++++------
src/backend/utils/adt/jsonfuncs.c | 27 ++++++++++++++++++++
src/test/regress/expected/jsonb.out | 27 ++++++++++++++++++++
src/test/regress/sql/jsonb.sql | 17 +++++++++++++
4 files changed, 102 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/json.sgml b/doc/src/sgml/json.sgml
index 07bd19f974..e16dd6973d 100644
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -614,8 +614,24 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
The result of a subscripting expression is always of the jsonb data type.
</para>
+ <para>
+ <command>UPDATE</command> statements may use subscripting in the
+ <literal>SET</literal> clause to modify <type>jsonb</type> values. Subscript
+ paths must be traversible for all affected values insofar as they exist. For
+ instance, the path <literal>val['a']['b']['c']</literal> can be traversed all
+ the way to <literal>c</literal> if every <literal>val</literal>,
+ <literal>val['a']</literal>, and <literal>val['a']['b']</literal> is an
+ object. If any <literal>val['a']</literal> or <literal>val['a']['b']</literal>
+ is not defined, it will be created as an empty object and filled as
+ necessary. However, if any <literal>val</literal> itself or one of the
+ intermediary values is defined as a non-object such as a string, number, or
+ <literal>jsonb</literal> <literal>null</literal>, traversal cannot proceed so
+ an error is raised and the transaction aborted.
+ </para>
+
<para>
An example of subscripting syntax:
+
<programlisting>
-- Extract object value by key
@@ -631,6 +647,10 @@ SELECT ('[1, "2", null]'::jsonb)[1];
-- value must be of the jsonb type as well
UPDATE table_name SET jsonb_field['key'] = '1';
+-- This will raise an error if any record's jsonb_field['a']['b'] is something
+-- other than an object. For example, the value {"a": 1} has no 'b' key.
+UPDATE table_name SET jsonb_field['a']['b']['c'] = '1';
+
-- Filter records using a WHERE clause with subscripting. Since the result of
-- subscripting is jsonb, the value we compare it against must also be jsonb.
-- The double quotes make "value" also a valid jsonb string.
@@ -639,8 +659,9 @@ SELECT * FROM table_name WHERE jsonb_field['key'] = '"value"';
<type>jsonb</type> assignment via subscripting handles a few edge cases
differently from <literal>jsonb_set</literal>. When a source <type>jsonb</type>
- is <literal>NULL</literal>, assignment via subscripting will proceed as if
- it was an empty JSON object:
+ value is <literal>NULL</literal>, assignment via subscripting will proceed
+ as if it was an empty JSON value of the type (object or array) implied by the
+ subscript key:
<programlisting>
-- Where jsonb_field was NULL, it is now {"a": 1}
@@ -661,17 +682,19 @@ UPDATE table_name SET jsonb_field[2] = '2';
</programlisting>
A <type>jsonb</type> value will accept assignments to nonexistent subscript
- paths as long as the last existing path key is an object or an array. Since
- the final subscript is not traversed, it may be an object key. Nested arrays
- will be created and <literal>NULL</literal>-padded according to the path until
- the value can be placed appropriately.
+ 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
+ <literal>null</literal>-padded, as specified by the subscript path until the
+ assigned value can be placed.
<programlisting>
-- Where jsonb_field was {}, it is now {'a': [{'b': 1}]}
UPDATE table_name SET jsonb_field['a'][0]['b'] = '1';
--- Where jsonb_field was [], it is now [{'a': 1}]
-UPDATE table_name SET jsonb_field[0]['a'] = '1';
+-- Where jsonb_field was [], it is now [null, {'a': 1}]
+UPDATE table_name SET jsonb_field[1]['a'] = '1';
</programlisting>
</para>
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index f14f6c3191..9138b7950e 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -4926,6 +4926,20 @@ setPath(JsonbIterator **it, Datum *path_elems,
switch (r)
{
case WJB_BEGIN_ARRAY:
+ /*
+ * If instructed complain about attempts to replace whithin a raw
+ * scalar value. This happens even when current level is equal to
+ * path_len, because the last path key should also correspond to an
+ * object or an array, not raw scalar.
+ */
+ if ((op_type & JB_PATH_FILL_GAPS) && (level <= path_len - 1) &&
+ v.val.array.rawScalar)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("cannot replace existing key"),
+ errdetail("The path assumes key is a composite object, "
+ "but it is a scalar value.")));
+
(void) pushJsonbValue(st, r, NULL);
setPathArray(it, path_elems, path_nulls, path_len, st, level,
newval, v.val.array.nElems, op_type);
@@ -4943,6 +4957,19 @@ setPath(JsonbIterator **it, Datum *path_elems,
break;
case WJB_ELEM:
case WJB_VALUE:
+ /*
+ * If instructed complain about attempts to replace whithin a
+ * scalar value. This happens even when current level is equal to
+ * path_len, because the last path key should also correspond to an
+ * object or an array, not an element or value.
+ */
+ if ((op_type & JB_PATH_FILL_GAPS) && (level <= path_len - 1))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("cannot replace existing key"),
+ errdetail("The path assumes key is a composite object, "
+ "but it is a scalar value.")));
+
res = pushJsonbValue(st, r, &v);
break;
default:
diff --git a/src/test/regress/expected/jsonb.out b/src/test/regress/expected/jsonb.out
index 5b5510c4fd..cf0ce0e44c 100644
--- a/src/test/regress/expected/jsonb.out
+++ b/src/test/regress/expected/jsonb.out
@@ -5134,6 +5134,33 @@ select * from test_jsonb_subscript;
1 | {"a": [null, {"c": [null, null, 1]}]}
(1 row)
+-- trying replace assuming a composite object, but it's an element or a value
+delete from test_jsonb_subscript;
+insert into test_jsonb_subscript values (1, '{"a": 1}');
+update test_jsonb_subscript set test_json['a']['b'] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+update test_jsonb_subscript set test_json['a']['b']['c'] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+update test_jsonb_subscript set test_json['a'][0] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+update test_jsonb_subscript set test_json['a'][0]['c'] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+update test_jsonb_subscript set test_json['a'][0][0] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+-- trying replace assuming a composite object, but it's a raw scalar
+delete from test_jsonb_subscript;
+insert into test_jsonb_subscript values (1, 'null');
+update test_jsonb_subscript set test_json[0] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
+update test_jsonb_subscript set test_json[0][0] = '1';
+ERROR: cannot replace existing key
+DETAIL: The path assumes key is a composite object, but it is a scalar value.
-- jsonb to tsvector
select to_tsvector('{"a": "aaa bbb ddd ccc", "b": ["eee fff ggg"], "c": {"d": "hhh iii"}}'::jsonb);
to_tsvector
diff --git a/src/test/regress/sql/jsonb.sql b/src/test/regress/sql/jsonb.sql
index 0320db0ea4..1a9d21741f 100644
--- a/src/test/regress/sql/jsonb.sql
+++ b/src/test/regress/sql/jsonb.sql
@@ -1371,6 +1371,23 @@ insert into test_jsonb_subscript values (1, '{"a": []}');
update test_jsonb_subscript set test_json['a'][1]['c'][2] = '1';
select * from test_jsonb_subscript;
+-- trying replace assuming a composite object, but it's an element or a value
+
+delete from test_jsonb_subscript;
+insert into test_jsonb_subscript values (1, '{"a": 1}');
+update test_jsonb_subscript set test_json['a']['b'] = '1';
+update test_jsonb_subscript set test_json['a']['b']['c'] = '1';
+update test_jsonb_subscript set test_json['a'][0] = '1';
+update test_jsonb_subscript set test_json['a'][0]['c'] = '1';
+update test_jsonb_subscript set test_json['a'][0][0] = '1';
+
+-- trying replace assuming a composite object, but it's a raw scalar
+
+delete from test_jsonb_subscript;
+insert into test_jsonb_subscript values (1, 'null');
+update test_jsonb_subscript set test_json[0] = '1';
+update test_jsonb_subscript set test_json[0][0] = '1';
+
-- jsonb to tsvector
select to_tsvector('{"a": "aaa bbb ddd ccc", "b": ["eee fff ggg"], "c": {"d": "hhh iii"}}'::jsonb);
--
2.21.0
--3x42k255okwqcjpg--
^ permalink raw reply [nested|flat] 4+ messages in thread
* New buildfarm animals with FIPS mode enabled
@ 2025-02-14 18:01 Tom Lane <[email protected]>
0 siblings, 2 replies; 4+ messages in thread
From: Tom Lane @ 2025-02-14 18:01 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
I see that somebody decided to crank up some animals running
RHEL8 and RHEL9 with FIPS mode turned on. The RHEL9 animals
pass on v17 and master, but not older branches; the RHEL8
animals pass nowhere. This is unsurprising given that the
v17-era commits that allowed our regression tests to pass
under FIPS mode (795592865 and a bunch of others) explicitly
targeted only OpenSSL 3:
These new expected files currently cover the FIPS mode provided by
OpenSSL 3.x as well as the modified OpenSSL 3.x from Red Hat (e.g.,
Fedora 38), but not the modified OpenSSL 1.x from Red Hat (e.g.,
Fedora 35). (The latter will have some error message wording
differences.)
I'm kind of disinclined to do all the work that'd be needed to turn
these animals completely green, especially when the reason to do it
seems to be that someone decided we should without any community
consultation. Perhaps others have different opinions though.
Thoughts?
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: New buildfarm animals with FIPS mode enabled
@ 2025-02-14 20:51 Daniel Gustafsson <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 4+ messages in thread
From: Daniel Gustafsson @ 2025-02-14 20:51 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; [email protected]
> On 14 Feb 2025, at 19:01, Tom Lane <[email protected]> wrote:
> I'm kind of disinclined to do all the work that'd be needed to turn
> these animals completely green, especially when the reason to do it
> seems to be that someone decided we should without any community
> consultation. Perhaps others have different opinions though.
If the owner of the BF animal shows up with a patch for providing alternative
outputs for the backbranches I don't mind accepting it, I'm not volunteering
myself to do more than review though.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: New buildfarm animals with FIPS mode enabled
@ 2025-02-15 16:55 Mark Wong <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 4+ messages in thread
From: Mark Wong @ 2025-02-15 16:55 UTC (permalink / raw)
To: Tom Lane <[email protected]>; [email protected]; +Cc: [email protected]
Hi Tom,
On 2/14/25 10:01 AM, Tom Lane wrote:
> I see that somebody decided to crank up some animals running
> RHEL8 and RHEL9 with FIPS mode turned on. The RHEL9 animals
> pass on v17 and master, but not older branches; the RHEL8
> animals pass nowhere. This is unsurprising given that the
> v17-era commits that allowed our regression tests to pass
> under FIPS mode (795592865 and a bunch of others) explicitly
> targeted only OpenSSL 3:
>
> These new expected files currently cover the FIPS mode provided by
> OpenSSL 3.x as well as the modified OpenSSL 3.x from Red Hat (e.g.,
> Fedora 38), but not the modified OpenSSL 1.x from Red Hat (e.g.,
> Fedora 35). (The latter will have some error message wording
> differences.)
>
> I'm kind of disinclined to do all the work that'd be needed to turn
> these animals completely green, especially when the reason to do it
> seems to be that someone decided we should without any community
> consultation. Perhaps others have different opinions though.
That's my fault. I did a sloppy job copying configs etc from the s390x
fips animals and forgot about the OS versions, branches, etc. Peter
Eisentraut reminded me I think I cleaned that all up.
Regards,
Mark
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-02-15 16:55 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 15:53 [PATCH v49 3/3] Replace assuming a composite object on a scalar Dmitrii Dolgov <[email protected]>
2025-02-14 18:01 New buildfarm animals with FIPS mode enabled Tom Lane <[email protected]>
2025-02-14 20:51 ` Re: New buildfarm animals with FIPS mode enabled Daniel Gustafsson <[email protected]>
2025-02-15 16:55 ` Re: New buildfarm animals with FIPS mode enabled Mark Wong <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox