Re: jsonb, unicode escapes and escaped backslashes - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: jsonb, unicode escapes and escaped backslashes
Date
Msg-id 54CAA730.5040002@dunslane.net
Whole thread Raw
In response to Re: jsonb, unicode escapes and escaped backslashes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: jsonb, unicode escapes and escaped backslashes
Re: jsonb, unicode escapes and escaped backslashes
List pgsql-hackers
On 01/29/2015 12:10 PM, Robert Haas wrote:
> On Wed, Jan 28, 2015 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The cause of this bug is commit 0ad1a816320a2b539a51628e2a0b1e83ff096b1d,
>> which I'm inclined to think we need to simply revert, not render even
>> more squirrely.
> Yes, that commit looks broken.  If you convert from text to JSON you
> should get a JSON string equivalent to the text you started out with.
> That commit departs from that in favor of allowing \uXXXX sequences in
> the text being converted to turn into a single character (or perhaps
> an encoding error) after a text->json->text roundtrip.  Maybe I
> haven't had enough caffeine today, but I can't see how that can
> possibly be a good idea.
>


Possibly.

I'm coming down more and more on the side of Tom's suggestion just to 
ban \u0000 in jsonb. I think that would let us have some fairly simple 
and consistent rules. I'm not too worried that we'll be disallowing 
input that we've previously allowed. We've done that often in the past, 
although less often in point releases. I certainly don't want to wait a 
full release cycle to fix this if possible.

cheers

andrew





pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Proposal: two new role attributes and/or capabilities?
Next
From: Jim Nasby
Date:
Subject: Re: Small bug on CREATE EXTENSION pgq...