Re: json_strip_nulls()

On Sat, 22 Jan 2022 at 20:31, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Sat, Jan 22, 2022 at 12:11 PM Erwin Brandstetter <brsaweda(at)gmail(dot)com>
> wrote:
>
>> But the function also strips all insignificant white space:
>> [...]
>> This is a useful feature to trim noise from json values, but unreliable
>> while undocumented. So let's document the behavior:
>>
>
> json_strip_nulls doesn't make any promise regarding its output json other
> than that it is valid. Since we are munging the json we are arguably
> within our rights to output whatever transformed version we want. The
> format should not be documented.
>

Within our rights, maybe. The manual makes related promises[1]:

> Because the json type stores an exact copy of the input text, it will
preserve semantically-insignificant white space between tokens

And[2]:

> As previously stated, when a JSON value is input and then printed without
any additional processing, json outputs the same text that was input,

Not strictly contradicting, but the current behavior of json_strip_nulls()
is still surprising. Either the input should be preserved as far as
possible or, failing that, the actual behavior documented.

[1] https://www.postgresql.org/docs/current/datatype-json.html
[2]
https://www.postgresql.org/docs/current/datatype-json.html#JSON-KEYS-ELEMENTS

>
>
>>
>> If that's undesirable, let's remove the functionality - and provide a
>> dedicated function for the task.
>>
>
> I agree we should at least provide a function that takes a json or jsonb
> and outputs its text representation in a minimalist form.
>
> I found similar (unresolved) considerations here:
>>
>> https://www.postgresql.org/message-id/20160610110633.GG18838%40zip.com.au
>>
>>
> This whole situation went through a fairly lengthy discussion back in 2016:
>
>
> https://www.postgresql.org/message-id/flat/CAH7T-ap6R_xzWz98c6AQzQuGsK_vpgr-et4VRaSjgxqom--ibw%40mail.gmail.com
>
> It's an interesting, and IMO, disappointing thread. Maybe we can do
> better now and focus on one missing capability the community desires and
> actually get something committed.
>

That would address the main issue here: to have a function doing that
reliably.

Regards
Erwin