Skip site navigation (1) Skip section navigation (2)

Re: json api WIP patch

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: james(at)mansionfamily(dot)plus(dot)com
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json api WIP patch
Date: 2013-01-08 20:22:13
Message-ID: 50EC7FF5.9010403@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On 01/08/2013 03:12 PM, Andrew Dunstan wrote:
>
> On 01/08/2013 09:58 AM, Andrew Dunstan wrote:
>>
>> If you have such a datum, parsing it involves having it in memory and 
>> then taking a copy (I wonder if we could avoid that step - will take 
>> a look).
>
>
> Here is a Proof Of Concept patch against my development tip on what's 
> involved in getting the JSON lexer not to need a nul-terminated string 
> to parse. This passes regression, incidentally. The downside is that 
> processing is very slightly more complex, and that json_in() would 
> need to call strlen() on its input. The upside would be that the 
> processing routines I've been working on would no longer need to 
> create copies of their json arguments using text_to_cstring() just so 
> they can get a null-terminated string to process.
>
> Consequent changes would modify the signature of makeJsonLexContext() 
> so it's first argument would be a text* instead of a char* (and of 
> course its logic would change accordingly).
>
> I could go either way. Thoughts?
>
>

this time with patch ...




Attachment: jsonparser.patch
Description: text/x-patch (6.6 KB)

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-08 20:26:36
Subject: Re: json api WIP patch
Previous:From: Andres FreundDate: 2013-01-08 20:18:08
Subject: Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group