On Fri, Mar 08, 2013 at 10:34:20PM +0100, Hannu Krosing wrote: > On 03/08/2013 10:01 PM, Alvaro Herrera wrote: >> Hannu Krosing escribi?: >>> If it does not meet these "semantic" constraints, then it is not >>> really JSON - it is merely JSON-like.
>> Is it wrong? The standard cited says SHOULD, not MUST. > > > I think one MAY start implementation with loose interpretation of > SHOULD, but if at all possible we SHOULD implement the > SHOULD-qualified features :) > > http://www.ietf.org/rfc/rfc2119.txt: > > SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. That "SHOULD" in section 2.2 of RFC 4627 constrains JSON data, not JSON parsers. Section 4 addresses parsers, saying "A JSON parser MUST accept all texts that conform to the JSON grammar." > We might start with just throwing a warning for duplicate keys, but I > can see no good reason to do so. Except ease of implementation and with > current JSON-AS-TEXT implenetation performance. Since its departure from a "SHOULD" item does not impugn the conformance of an input text, it follows that json_in(), to be a conforming JSON parser, MUST not reject objects with duplicate keys. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers