Re: Duplicate JSON Object Keys
От | Gavin Flower |
---|---|
Тема | Re: Duplicate JSON Object Keys |
Дата | |
Msg-id | 5140AE9E.8010406@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Duplicate JSON Object Keys (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Duplicate JSON Object Keys
(Andrew Dunstan <andrew@dunslane.net>)
|
Список | pgsql-hackers |
<div class="moz-cite-prefix">On 14/03/13 02:02, Andrew Dunstan wrote:<br /></div><blockquote cite="mid:514078E1.2090905@dunslane.net"type="cite"><br /> On 03/13/2013 08:17 AM, Robert Haas wrote: <br /><blockquote type="cite">OnFri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan <a class="moz-txt-link-rfc2396E" href="mailto:andrew@dunslane.net"><andrew@dunslane.net></a>wrote: <br /><blockquote type="cite"><blockquote type="cite">Somy order of preference for the options would be: <br /><br /> 1. Have the JSON type collapse objects so thelast instance of a key wins <br /> and is actually stored <br /><br /> 2. Throw an error when a JSON type has duplicatekeys <br /><br /> 3. Have the accessors find the last instance of a key and return that <br /> value <br /><br />4. Let things remain as they are now <br /><br /> On second though, I don't like 4 at all. It means that the JSON type<br /> things a value is valid while the accessor does not. They contradict one <br /> another. <br /></blockquote> Youcan forget 1. We are not going to have the parser collapse anything. <br /> Either the JSON it gets is valid or it's not.But the parser isn't going to <br /> try to MAKE it valid. <br /></blockquote> Why not? Because it's the wrong thingto do, or because it would be slower? <br /><br /> What I think is tricky here is that there's more than one way to<br /> conceptualize what the JSON data type really is. Is it a key-value <br /> store of sorts, or just a way to storetext values that meet certain <br /> minimalist syntactic criteria? I had imagined it as the latter, in <br /> whichcase normalization isn't sensible. But if you think of it the <br /> first way, then normalization is not only sensible,but almost <br /> obligatory. For example, we don't feel bad about this: <br /><br /> rhaas=# select '1e1'::numeric;<br /> numeric <br /> --------- <br /> 10 <br /> (1 row) <br /><br /> I think Andrew and I had envisionedthis as basically a text data type <br /> that enforces some syntax checking on its input, hence the current <br/> design. But I'm not sure that's the ONLY sensible design. <br /><br /></blockquote><br /><br /> I think we've movedon from this point, because a) other implementations allow duplicate keys, b) it's trivially easy to make Postgres generatesuch json, and c) there is some dispute about exactly what the spec mandates. <br /><br /> I'll be posting a revisedpatch shortly that doesn't error out but simply uses the value for the later key lexically. <br /><br /> cheers <br/><br /> andrew <br /><br /><br /><br /><br /></blockquote><font size="-1">How about adding a new func<font size="-1">tionwith '_stric<font size="-1">t' added to the existing name, with an extra parameter </font></font></font>'coalesce'- or using other names, if considered more appropriate!<br /><br /> That way slower more stringentfunctionality can be added where required. This way, the existing function need not be changed.<br /><br /> Ifcoalesce = true, <br /> then: the last duplicate is used<br /> else: an error is returned when the new key is a duplicate.<br/><br /><br /> Cheers,<br /> Gavin<br /><br /><br /><br />
В списке pgsql-hackers по дате отправления: