Re: jsonb, unicode escapes and escaped backslashes

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: jsonb, unicode escapes and escaped backslashes
Дата
Msg-id 54CAB49E.3020100@dunslane.net
обсуждение исходный текст
Ответ на Re: jsonb, unicode escapes and escaped backslashes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: jsonb, unicode escapes and escaped backslashes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 01/29/2015 04:59 PM, Robert Haas wrote:
> On Thu, Jan 29, 2015 at 4:33 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> 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.
> I have yet to understand what we fix by banning \u0000.  How is 0000
> different from any other four-digit hexadecimal number that's not a
> valid character in the current encoding?  What does banning that one
> particular value do?
>
> In any case, whatever we do about that issue, the idea that the text
> -> json string transformation can *change the input string into some
> other string* seems like an independent problem.
>

jsonb stores string values as postgres text values, with the unicode 
escapes resolved, just as it also resolves numbers and booleans into 
their native representation.  If you want the input perfectly preserved, 
use json, not jsonb.  I think that's made pretty clear in the docs.

so text->jsonb->text is not and has never been expected to be a noop.

cheers

andrew



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Misaligned BufferDescriptors causing major performance problems on AMD
Следующее
От: Tom Lane
Дата:
Сообщение: Re: jsonb, unicode escapes and escaped backslashes