From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: nested hstore patch |
Date: | 2014-01-10 18:45:16 |
Message-ID: | 52D03FBC.5090707@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/10/2014 01:29 PM, Robert Haas wrote:
> On Thu, Jan 9, 2014 at 5:08 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> * The jsonb regression test currently contains U+ABCD - I guess we'd
>> better use some hex encoding or whatever for that - unlike json, the
>> jsonb de-serializer dissolves unicode escapes.
> How does that work if the server encoding isn't UTF-8?
>
There is a jsonb_1.out file for the non-utf8 case, just as there is a
json_1.out for the same case. Unicode escapes for non-ascii characters
are forbidden in jsonb as they are in json, if the encoding isn't utf8.
FYI, we are actually using the json lexing and parsing mechanism, so
that these types will accept exactly the same inputs. However, since
we're not storing json text in jsonb, but instead the decomposed
elements, the unicode escapes are resolved in the stored values.
I already have a fix for the point above (see
<https://github.com/feodor/postgres/commit/7d5b8f12747b4a75e8b32914340d07617f1af302>)
and it will be included in the next version of the patch.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-01-10 18:47:02 | Re: new json funcs |
Previous Message | Peter Geoghegan | 2014-01-10 18:37:03 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |