Dmitry Dolgov wrote:
>> On 6 April 2018 at 16:25, Teodor Sigaev <teodor@sigaev.ru> wrote:
>> 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new
>> variant to index? Let me suggest:
>>
>> tsvector jsonb_to_tsvector([regclass,] jsonb, text[])
>>
>> where text[] arg is actually a flags, array contains any combination of
>> literals 'numeric', 'string', 'boolean' (and even 'key' to index keys_ to
>> point which types should be indexed. More than it, may be, it should a jsonb
>> type for possible improvements in future. For now, it shouldbe a jsonb array
>> type with string elements described above, example:
>>
>> select jsonb_to_tsvector('{"a": "aaa in bbb ddd ccc", "b":123}',
>> '["numeric", "boolean"]');
>>
>>
>> Form jsonb_to_tsvector('...', '["string"]) is effectively the same as
>> current to_tsvector(jsonb)
>
> Thank you for the suggestion, this sounds appealing. But I have two questions:
>
> * why it should be a jsonb array, not a regular array?
To simplify extension of this array in future, for example to add limitation of
recursion level in converted jsonb, etc.
>
> * it would introduce the idea of jsonb element type expressed in text format,
> so "string", "numeric", "boolean" etc - are there any consequences of that?
> As far as I understand so far there was only jsonb_typeof.
Good catch, jsonb_typeof strings are okay: "string", "number", "boolean"
also "all", "key", "value"
See workable sketch for parsing jsonb flags and new worker variant.
>> 2) Now it fails, and I see something strange in resuling tsvector
>
> Oh, sorry, stupid copy-paste mistake in the condition. Just for the records,
> I've attached fixed version of the previous patch (without any changes about an
> array instead of a boolean flag).
by the way:
Datum
jsonb_to_tsvector(PG_FUNCTION_ARGS)
{
Jsonb *jb = PG_GETARG_JSONB_P(0);
...
PG_FREE_IF_COPY(jb, 1); //wrong arg number
}
jsonb_all_to_tsvector and json variants too
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/