Re: jsonb, unicode escapes and escaped backslashes

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: jsonb, unicode escapes and escaped backslashes
Дата
Msg-id 54CAA730.5040002@dunslane.net
обсуждение исходный текст
Ответ на Re: jsonb, unicode escapes and escaped backslashes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: jsonb, unicode escapes and escaped backslashes  (Andres Freund <andres@2ndquadrant.com>)
Re: jsonb, unicode escapes and escaped backslashes  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: two new role attributes and/or capabilities?
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Small bug on CREATE EXTENSION pgq...