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.
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
