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

Re: json api WIP patch

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json api WIP patch
Date: 2013-01-15 00:36:00
Message-ID: CAHyXU0watb0hOpF0DQ1v5Hx2TX=406RS6+OoszZG1Vc88jF85g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 10, 2013 at 5:42 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 01/04/2013 03:23 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/02/2013 05:51 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/02/2013 04:45 PM, Robert Haas wrote:
>>>>
>>>> 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.
>>
>>
>>
>> Udated patch that contains most of the functionality I'm after. One piece
>> left is populate_recordset (populate a set of records from a single json
>> datum which is an array of objects, in one pass). That requires a bit of
>> thought.
>>
>> I hope most of the whitespace issues are fixed.
>>
>>
>
>
> This updated patch contains all the intended functionality, including
> operators for the json_get_path functions, so you can say things like
>
>     select jsonval->array['f1','0','f2] ...
>
> It also removes any requirement to copy the json value before setting up the
> lexer by removing the lexer's requirement to have a nul terminated string.
> Instead the lexer is told the input length and relies on that. For this
> reason, json_in() now calls cstring_get_text() before rather than after
> calling the validation routine, but that's really not something worth
> bothering about.
>
> A couple of points worth noting: it's a pity that we have to run CREATE OR
> REPLACE FUNCTION in system_views.sql in order to set up default values for
> builtin functions. That feels very kludgy. Also, making operators for
> variadic functions is a bit of a pain. I had to set up non-variadic version
> of the same functions (see json_get_path_op and json_get_path_as_text_op)
> just so I could set up the operators. Neither of these are exactly
> showstopper items, just mild annoyances.
>
> I will continue hunting memory leaks, but when Merlin gets done with docco I
> think we'll be far enough advanced to add this to the commitfest.

While testing this I noticed that integer based 'get' routines are
zero based -- was this intentional?  Virtually all other aspects of
SQL are 1 based:

postgres=# select json_get('[1,2,3]', 1);
 json_get
----------
 2
(1 row)

postgres=# select json_get('[1,2,3]', 0);
 json_get
----------
 1
(1 row)

merlin


In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-15 00:52:56
Subject: Re: json api WIP patch
Previous:From: Andres FreundDate: 2013-01-14 23:29:07
Subject: [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body

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