Re: [HACKERS] [PATCH] few fts functions for jsonb - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] [PATCH] few fts functions for jsonb
Date
Msg-id 9c97e73b-fa84-0711-b408-3a6e2d89ea96@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] few fts functions for jsonb  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: [PATCH] few fts functions for jsonb  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers

On 03/21/2017 06:28 PM, Dmitry Dolgov wrote:
> > On 21 March 2017 at 03:03, Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com
> <mailto:andrew.dunstan@2ndquadrant.com>> wrote:
> >
> > However, I think it should probably be broken up into a couple of
> pieces -
> > one for the generic json/jsonb transforms infrastructure (which probably
> > needs some more comments) and one for the FTS functions that will
> use it.
>
> Sure, here are two patches with separated functionality and a bit more
> commentaries for the transform functions.

I'm not through looking at this. However, here are a few preliminary
comments
 * we might need to rationalize the header locations a bit * iterate_json(b) and transform_json(b) are a bit too
generallynamed.   Really what they do is iterate over or transform string values in   the json(b). They ignore /
preservethe structure, keys, and   non-string scalar values in the json(b). A general iterate or   transform function
wouldbe called in effect with a stream of all   the elements in the json, not just scalar strings. * Unless I'm missing
somethingthe iterate_json(b)_values return value   is ignored. Instead of returning the state it looks to me like it
shouldreturn nothing and be declared as void instead of void * * transform_jsonb and transform_json are somewhat
asymmetrical.The   latter should probably return a text* instead of a StringInfo, to be   consistent with the former.
 

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] pg_dump, pg_dumpall and data durability
Next
From: Michael Banck
Date:
Subject: Re: [HACKERS] Logical replication existing data copy