Generic JSON API

From: Nikita Malakhov <hukutoc(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Generic JSON API
Date: 2022-03-29 09:41:47
Message-ID: CAN-LCVMH_S25KwKT=5rHskqBN=OKr3SOVPrsF0-XHvwCjp5GAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hackers!

Postgres Pro team would like to present a result of several years'
development - a Generic JSON (GSON) API, announced in 2020 as "The Grand
Unification". Finally, it is ready and awaiting review.
For the sake of compatibility with SQL standard we need one JSON data type,
which is internally
- jsonb by default, to optimize json objects storage;
- Optionally behave as "old textual json" for the cases demanding full Json
text representation;
And, logically, here comes the idea of Generic JSON.
Current JSON API is different for json and jsonb data types:
- Json has lexer and parser with visitor interface;
- Jsonb uses Json lexer and parser for input, and several functions and
iterators for access.
This makes difficult to implement jsonpath functions for json (required by
the SQL standard)
and GIN indexes for json.
Also, it makes very difficult to add new features like partial
decompression/detoasting or
slicing, different storage formats, etc.

Generic JSON (GSON) — New API
- New generic JSON API is based on jsonb API:
- JSON datums, containers, and iterators are wrapped into generic Json,
JsonContainer,
and JsonIterator structures.
- JsonbValue and its builder function pushJsonbValue() are renamed and used
as is.
- All container-specific functions are hidden into JsonContainerOps, which
has three
implementations:
- JsonbContainerOps for jsonb
- JsontContainerOps for json
- JsonvContainerOps for in-memory tree-like JsonValue
For json only iterators need to be implemented, access functions are
implemented using these
iterators.
And as an icing on the cake GSON allows using JSONb as SQL JSON.

New GSON functionality is available on github as
https://github.com/postgrespro/postgres/tree/gson
We decided to divide this functionality into the set of patches:

1) 1_json_prep_rebased.patch.gz. Improvements and refactoring of existing
JSONb interface, as
preparation for introducing new Generic JSON - hiding internal variables,
functions used in API
are extracted in Json structures, and assembling future GSON generic
function set;

2) 2_generic_json.patch.gz. New GSON (Generic JSON) interface itself - data
wrappers, generic
set of functions, JSONb redirect via new API. GSON is defined as new header
json_generic.h
and C source json_generic.c. All internal operations are hidden inside
generic function set;

3) 3_tmp_stack_allocated_json.patch.gz. Allocation of temporary JSONb
objects on stack, with
freeing when they are not needed anymore;

4) 4_generic_json_refactoring.patch.gz. GSON refactoring and optimization -
adding JsonCopy,
JsonValueCopy container operations, container allocation function, hiding
direct internal fields access, excluding jsonv functions;

5) 5_gson_refactoring_1.patch.gz. Further refactoring and optimization -
getting rid of old
jsonx and jsont macros and functions, introducing Json container header
with parting container
data and header, and hiding into header structure.

The main contributor of GSON is Postgres Pro developer Nikita Glukhov with
the guidance of Oleg Bartunov.

We're waiting for community' review, and of course proposals, advices,
questions and further discussions.
Thank you!

--
Regards,
Nikita Malakhov
Postgres Professional
https://postgrespro.ru/

Attachment Content-Type Size
3_tmp_stack_allocated_json.patch.gz application/x-gzip 3.6 KB
5_gson_refactoring_1.patch.gz application/x-gzip 10.2 KB
4_generic_json_refactoring.patch.gz application/x-gzip 9.9 KB
1_json_prep_rebased.patch.gz application/x-gzip 10.6 KB
2_generic_json.patch.gz application/x-gzip 22.3 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message gkokolatos 2022-03-29 09:46:27 Re: Add LZ4 compression in pg_dump
Previous Message shiy.fnst@fujitsu.com 2022-03-29 09:35:28 RE: logical replication empty transactions