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

Re: json api WIP patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json api WIP patch
Date: 2013-01-02 21:45:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Dec 26, 2012 at 3:33 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Here is a patch for the first part of the JSON API that was recently
> discussed. It includes the json  parser hook infrastructure and functions
> for json_get and friends, plus json_keys.
> As is, this exposes the json lexer fully for use by the hook functions. But
> I could easily be persuaded that this should be an opaque structure with
> some constructor and getter functions - I don't think the hook functions
> need or should be able to set anything in the lexer.
> Work is proceeding on some of the more advanced functionality discussed.

This seems to contain a large number of spurious whitespace changes.

And maybe some other spurious changes.  For example, I'm not sure why
this comment is truncated:


! 	/*
! 	 * Check for trailing garbage.  As in json_lex(), any alphanumeric stuff
! 	 * here should be considered part of the token for error-reporting
! 	 * purposes.
! 	 */
  	for (p = s; JSON_ALPHANUMERIC_CHAR(*p); p++)
  		error = true;
  	lex->token_terminator = p;
  	if (error)
--- 730,739 ----

! 	/* Check for trailing garbage. */
  	for (p = s; JSON_ALPHANUMERIC_CHAR(*p); p++)
  		error = true;
+ 	lex->prev_token_terminator = lex->token_terminator;
  	lex->token_terminator = p;
  	if (error)

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-02 21:51:40
Subject: Re: Whats the correct way to change trigdata->tg_relation
Previous:From: Robert HaasDate: 2013-01-02 21:38:41
Subject: Re: Feature Request: pg_replication_master()

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