Re: JSON validation behavior

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Sergei Kornilov <sk(at)zsrv(dot)org>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JSON validation behavior
Date: 2018-10-24 14:40:00
Message-ID: CAKFQuwbV9s_HE8p+zhPCavZ+GAbaYge8weZMA69-_GcqibiCEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2018-10-24 14:47:37 Re: Estimating number of distinct values.
Previous Message Tom Lane 2018-10-24 14:27:19 Re: Estimating number of distinct values.