On 06/11/2013 03:54 PM, Andrew Dunstan wrote:
>
> On 06/11/2013 09:23 AM, Hannu Krosing wrote:
>
>>
>> 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.
>
> You are quite wrong. This was discussed quite recently on -hackers, too.
> V8 will happily accept a JSON string with duplicate keys via eval()
> and resolve it in favor of the lexically latest value.
This is what I mean.
It is a valid _input_ value , but no existing JavaScript structure
serializes to it.
In other words - I want us to have in minds some underlying structure,
not the text
hannu=# select '1e0'::float;float8
-------- 1
(1 row)
we are not preserving '1e0' in floats, why should we preserve it in
json () ?
We do imply an internal structured format in several functions operating
on json even though we store it in text .
> I gather most other JSON processors do likewise.
>
>
> Can we PLEASE PLEASE stop sending this discussion off track and
> concentrate on the actual problem we have at hand? It's BETA and there
> is not much time.
> I get that you don't like how we have implemented JSON.
The current implementation is a reasonably good compromise, so I can't
say I don't like it :)
I am here going from the premise that at some point we might implement a
json-like binary structured type.
If it is left separate from json, I am ok with all kinds of quirks
coming from current vague definition of what a "json type" is.
OTOH, if the idea is to move "json" storage format to this binary
structured type, we should resolve
possible incompatibilities as early as possible and start thinking of
the current "as text" storage in terms
of something that is a real structured type, just stored in text format.
This could also mean converting to canonical format on input.
> But we're not going back over that ground now. It's done and in use
> and LOTS of people are finding it very useful.
I am one of these people who finds it very useful.
I just want to avoid painting us in a corner too early.
I would like us to have *one* json type in the future, not separate
"json input string" and "json compatible binary structure" or somesuch
>
>
> cheers
>
> andrew
>
>
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ