On 03/08/2013 10:42 PM, Andrew Dunstan wrote:
On 03/08/2013 04:28 PM, David E. Wheeler wrote:
On Mar 8, 2013, at 1:21 PM, Andrew Dunstan <and...@dunslane.net> wrote:
Here's what rfc2119 says about that wording:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
I suspect this was allowed for the JavaScript behavior where multiple
keys are allowed, but the last key in the list wins.
So we're allowed to do as Robert chose, and I think there are good
reasons for doing so (apart from anything else, checking it would
slow down the parser enormously).
Yes, but the implications are going to start biting us on the ass now.
Now you could argue that in that case the extractor functions should
allow it too, and it's probably fairly easy to change them to allow
it. In that case we need to decide who wins. We could treat a later
field lexically as overriding an earlier field of the same name,
which I think is what David expected. That's what plv8 does (i.e.
it's how v8 interprets JSON):
andrew=# create or replace function jget(t json, fld text) returns
text language plv8 as ' return t[fld]; ';
CREATE FUNCTION
andrew=# select jget('{"f1":"x","f1":"y"}','f1');
jget
------
y
(1 row)
Or you could take the view I originally took that in view of the RFC
wording we should raise an error if this was found.
I can live with either view.
I’m on the fence. On the one hand, I like the plv8 behavior, which is
nice for a dynamic language. On the other hand, I don't much care for
it in my database, where I want data storage requirements to be quite
strict. I hate the idea of "0000-00-00" being allowed as a date, and
am uncomfortable with allowing duplicate keys to be stored in the
JSON data type.
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.
Ok, so the "make valid" part will have to wait for
http://www.pgcon.org/2013/schedule/events/518.en.html if this will ever
happen ;)
Which means that all extractor functions will need to do much more work
in case of complex json, think of
json_get('("a":{"b":1},"a":{"1":"x"}, "a":[1,{"b":7}]}'::json,
["a","1","b"])
the true value in javascript is but here the get_json function has several
options to error out early and real confusion as to where to report the
error if in the end it is not found. essentially all extractor functions
have
to do what we omitted doing at input time.
Cheers
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
