Re: JSON validation behavior - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: JSON validation behavior
Date
Msg-id CAKFQuwbV9s_HE8p+zhPCavZ+GAbaYge8weZMA69-_GcqibiCEg@mail.gmail.com
Whole thread Raw
In response to JSON validation behavior  (Sergei Kornilov <sk@zsrv.org>)
Responses Re: JSON validation behavior  (Sergei Kornilov <sk@zsrv.org>)
Re: JSON validation behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Oct 24, 2018 at 7:25 AM Sergei Kornilov <sk@zsrv.org> wrote:

DETAIL:  \u0000 cannot be converted to text.

Well, requested text type can not have \u0000 byte. But seems strange: we test json type with this value but raise same error for -> operator:

We allow write such json to table, we allow read whole json, but we can not use native operators. Is this behavior expected?

It isn't that different than saying:

'123bcd'::integer -- error, invalid input for type integer

While text can hold just about everything it cannot contain an actual ASCII NUL character and so a JSON value with a unicode represented NUL cannot be converted to text.  Text doesn't have a stored concept of escaped values, using escape is only valid during entry.

The following does seem buggy though:

select json '{ "a": "null \u0000 escape"}' -> 'a' as fails; 

The final result should be json yet somewhere it seems there is an intermediate text being constructructed and that implementation detail is causing an error in an otherwise valid situation.

David J.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Estimating number of distinct values.
Next
From: Jeff Janes
Date:
Subject: Re: Estimating number of distinct values.