Re: json api WIP patch - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: json api WIP patch
Date
Msg-id CAHyXU0watb0hOpF0DQ1v5Hx2TX=406RS6+OoszZG1Vc88jF85g@mail.gmail.com
Whole thread Raw
In response to Re: json api WIP patch  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json api WIP patch
List pgsql-hackers
On Thu, Jan 10, 2013 at 5:42 PM, Andrew Dunstan <andrew@dunslane.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@dunslane.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: [PATCH] Compile without warning with gcc's -Wtype-limits, -Wempty-body
Next
From: Andrew Dunstan
Date:
Subject: Re: json api WIP patch