|From:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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 ...
|Next Message||Andrew Dunstan||2013-01-08 20:26:36||Re: json api WIP patch|
|Previous Message||Andres Freund||2013-01-08 20:18:08||Re: [PATCH 1/5] Centralize Assert* macros into c.h so its common between backend/frontend|