On 03/08/2013 11:03 PM, Andrew Dunstan wrote:
On 03/08/2013 04:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key
wins and is actually stored
2. Throw an error when a JSON type has duplicate keys
3. Have the accessors find the last instance of a key and return
that value
4. Let things remain as they are now
On second though, I don't like 4 at all. It means that the JSON type
things a value is valid while the accessor does not. They contradict
one another.
You can forget 1. We are not going to have the parser collapse
anything. Either the JSON it gets is valid or it's not. But the
parser isn't going to try to MAKE it valid.
Actually, now I think more about it 3 is the best answer.
Here's why: even the JSON generators can produce JSON with non-unique
field names:
Yes, especially if you consider popular json generators vim and strcat() :)
It is not a "serialisation" of some existing object, but it is something
that JavaScript could interpret as valid subset of JavaScript which
producees a JavaScript Object when interpreted.
In this sense it is way better than MySQL timestamp 0000-00-00 00:00
So the loose (without implementing the SHOULD part) meaning of
JSON spec is "anything that can be read into JavaScript producing
a JS Object" and not "serialisation of a JavaScript Object" as I wanted
to read it initially.
andrew=# select row_to_json(q) from (select x as a, y as a from
generate_series(1,2) x, generate_series(3,4) y) q;
row_to_json
---------------
{"a":1,"a":3}
{"a":1,"a":4}
{"a":2,"a":3}
{"a":2,"a":4}
So I think we have no option but to say, in terms of rfc 2119, that we
have careful considered and decided not to comply with the RFC's
recommendation
The downside is, that the we have just shifted the burden of JS Object
generation to the getter functions.
I suspect that 99.98% of the time we will get valid and unique JS Object
serializations or equivalent as input to json_in()
If we want the getter functions to handle the "loose JSON" to Object
conversion
side assuming our stored JSON can contain non-unique keys then these are
bound to be slower, as they have to do these checks. Thay can't just
grab the first
matching one and return or recurse on that.
(and we should note that in the docs).
definitely +1
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
