| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Cc: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Duplicate JSON Object Keys |
| Date: | 2013-03-13 17:59:21 |
| Message-ID: | 5140BE79.3010405@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03/13/2013 01:50 PM, David E. Wheeler wrote:
> On Mar 13, 2013, at 10:45 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> If someone wants functions to enforce a stricter validity check (e.g. via a check constraint on a domain), or to convert json to a canonical version which strips out prior keys of the same name and their associated values, then these should be relatively simple to implement given the parser API in the current patch. But they aren't part of the current patch, and I think it's way too late to be adding such things.
> I think it might be good to get something like this into core eventually, otherwise I suspect that there will be a different version of it for every JSON-using project out there. And my first cut at it won’t descend into sub-objects.
The you wouldn't be doing it right. The whole thing about a recursive
descent parser is that it's, well, recursive.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2013-03-13 18:32:06 | Re: Duplicate JSON Object Keys |
| Previous Message | David E. Wheeler | 2013-03-13 17:50:28 | Re: Duplicate JSON Object Keys |