From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb, unicode escapes and escaped backslashes |
Date: | 2015-01-29 21:33:36 |
Message-ID: | 54CAA730.5040002@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/29/2015 12:10 PM, Robert Haas wrote:
> On Wed, Jan 28, 2015 at 12:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-01-29 21:42:03 | Re: Small bug on CREATE EXTENSION pgq... |
Previous Message | Jim Nasby | 2015-01-29 21:09:31 | Re: Proposal: two new role attributes and/or capabilities? |