pgsql: Support JSON negative array subscripts everywhere

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Support JSON negative array subscripts everywhere
Date: 2015-07-18 01:14:25
Message-ID: E1ZGGht-0001nj-9s@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Support JSON negative array subscripts everywhere

Previously, there was an inconsistency across json/jsonb operators that
operate on datums containing JSON arrays -- only some operators
supported negative array count-from-the-end subscripting. Specifically,
only a new-to-9.5 jsonb deletion operator had support (the new "jsonb -
integer" operator). This inconsistency seemed likely to be
counter-intuitive to users. To fix, allow all places where the user can
supply an integer subscript to accept a negative subscript value,
including path-orientated operators and functions, as well as other
extraction operators. This will need to be called out as an
incompatibility in the 9.5 release notes, since it's possible that users
are relying on certain established extraction operators changed here
yielding NULL in the event of a negative subscript.

For the json type, this requires adding a way of cheaply getting the
total JSON array element count ahead of time when parsing arrays with a
negative subscript involved, necessitating an ad-hoc lex and parse.
This is followed by a "conversion" from a negative subscript to its
equivalent positive-wise value using the count. From there on, it's as
if a positive-wise value was originally provided.

Note that there is still a minor inconsistency here across jsonb
deletion operators. Unlike the aforementioned new "-" deletion operator
that accepts an integer on its right hand side, the new "#-" path
orientated deletion variant does not throw an error when it appears like
an array subscript (input that could be recognized by as an integer
literal) is being used on an object, which is wrong-headed. The reason
for not being stricter is that it could be the case that an object pair
happens to have a key value that looks like an integer; in general,
these two possibilities are impossible to differentiate with rhs path
text[] argument elements. However, we still don't allow the "#-"
path-orientated deletion operator to perform array-style subscripting.
Rather, we just return the original left operand value in the event of a
negative subscript (which seems analogous to how the established
"jsonb/json #> text[]" path-orientated operator may yield NULL in the
event of an invalid subscript).

In passing, make SetArrayPath() stricter about not accepting cases where
there is trailing non-numeric garbage bytes rather than a clean NUL
byte. This means, for example, that strings like "10e10" are now not
accepted as an array subscript of 10 by some new-to-9.5 path-orientated
jsonb operators (e.g. the new #- operator). Finally, remove dead code
for jsonb subscript deletion; arguably, this should have been done in
commit b81c7b409.

Peter Geoghegan and Andrew Dunstan

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/e02d44b8a74810341c90add4cd49e428b9d406b9

Modified Files
--------------
doc/src/sgml/func.sgml | 16 ++++--
src/backend/utils/adt/json.c | 39 +++++++++++++
src/backend/utils/adt/jsonfuncs.c | 100 ++++++++++++++++++++++++---------
src/include/utils/jsonapi.h | 7 +++
src/test/regress/expected/json.out | 14 +++++
src/test/regress/expected/json_1.out | 14 +++++
src/test/regress/expected/jsonb.out | 30 ++++++++++
src/test/regress/expected/jsonb_1.out | 30 ++++++++++
src/test/regress/sql/json.sql | 5 ++
src/test/regress/sql/jsonb.sql | 5 ++
10 files changed, 231 insertions(+), 29 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2015-07-18 13:15:28 Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY
Previous Message Andrew Dunstan 2015-07-18 01:11:13 pgsql: Support JSON negative array subscripts everywhere