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
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 |