From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Erwin Brandstetter <brsaweda(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: json_strip_nulls() |
Date: | 2022-01-22 21:00:39 |
Message-ID: | 1489048.1642885239@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Erwin Brandstetter <brsaweda(at)gmail(dot)com> writes:
> On Sat, 22 Jan 2022 at 20:31, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
> wrote:
>> 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,
"Without any additional processing" is the key restriction there.
> 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.
It is documented --- you just quoted the text that does so.
I don't have a lot of sympathy for "JSON-reading" code that fails to
conform to the JSON RFC, so I'm disinclined to work harder than that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Erwin Brandstetter | 2022-01-23 07:44:28 | Re: json_strip_nulls() |
Previous Message | Tom Lane | 2022-01-22 20:45:32 | Re: array_to_string and string_to_array |