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:12:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?



In response to


pgsql-hackers by date

Next: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
Previous:From: jamesDate: 2013-01-08 20:07:12
Subject: Re: json api WIP patch

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