Re: JSON validation behavior

From: Sergei Kornilov <sk(at)zsrv(dot)org>
To: David G(dot) Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JSON validation behavior
Date: 2018-10-24 15:09:41
Message-ID: 160951540393781@myt1-8f46c049cd43.qloud-c.yandex.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

24.10.2018, 17:40, "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>:
> On Wed, Oct 24, 2018 at 7:25 AM Sergei Kornilov <sk(at)zsrv(dot)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.
Yes, it is reasonable for operators which returns text, such as ->> (and i do not have question on this)
I was surprised by operators with json type result

regards, Sergei

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sandeep Thakkar 2018-10-24 15:43:35 Re: Problem with EDB 11.0 Windows x64 distributions
Previous Message Fabien COELHO 2018-10-24 15:08:00 Re: pgbench - add pseudo-random permutation function