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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
jsonparser.patch text/x-patch 6.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
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