Re: json api WIP patch

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: james@mansionfamily.plus.com
Cc: Merlin Moncure <mmoncure@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-01-08T20:22:13Z
Lists: pgsql-hackers

Attachments

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