Re: JSON and unicode surrogate pairs

On 06/11/2013 03:08 PM, Stefan Drees wrote:
> quiring preserving "original text" in json data field is Not Good!
>>
>> I fully expect '{"a":1, "a":none, "a":true, "a":"b"}'::json to come out
>> as '{"a":b"}'
>
> ahem, do you mean instead to give (none -> null and missing '"'
> inserted in "answer"):
yeah, mixed up none and null
> =# SELECT '{"a":1, "a":null, "a":true, "a":"b"}'::json;
> json
> --------------------------------------
> {"a":"b"}
>
> or only when "stored" in database and subsequently retrieved? The
> "original text" in this case was perfectly valid JSON text.
>
>> (I know that currently this is noty true and will happen only once I
>> read in the json value in client)
>
> Isn't this a good situation and doesn't this also depend on the
> storage representation in the client?
>
> What about this:
> =# SELECT '{"measure":"seconds", "measure":42}'::json;
> json
> --------------------------------------
> {"measure":42}
>
> I presume people being used to store metadata in "preceding" json
> object members with duplicate names, would want to decide in the
> client requesting the data what to do with the metadata information
> and at what point to "drop", wouldn't they :-?)
Seems like blatant misuse of JSON format :)

I assume that as JSON is _serialisation_ format, it should represent a
data structure, not processing instructions.

I can see no possible JavaScript structure which could produce duplicate
key when serialised.

And I don't think that any standard JSON reader supports this either.

Of you want to store any JavaScript snippets in database use text.

Or perhaps pl/v8 :)

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ