Re: jsonb generation functions

In the jsonb patch I have been working on, I have replicated all of what
I call the json processing functions, and I will shortly add analogs for
the new functions in that category json_to_record and json_to_recordset.

However I have not replicated what I call the json generation functions,
array_to_json, row_to_json, to_json, and the new functions
json_build_array, json_build_object, and json_object, nor the aggregate
functions json_agg and the new json_object_agg. The reason for that is
that I have always used those for constructing json given to the client,
rather than json stored in the database, and for such a use there would
be no point in turning it into jsonb rather than generating the json
string directly.

However, I could be persuaded that we should have a jsonb analog of
every json function. If we decide that, the next question is whether we
have to have it now, or if it can wait.

(The other notable thing that's missing, and I think can't wait, is
casts from json to jsonb and vice versa. I'm going to work on that
immediately.)

cheers

andrew

On Wed, Jan 29, 2014 at 9:08 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> In the jsonb patch I have been working on, I have replicated all of what I
> call the json processing functions, and I will shortly add analogs for the
> new functions in that category json_to_record and json_to_recordset.
>
> However I have not replicated what I call the json generation functions,
> array_to_json, row_to_json, to_json, and the new functions json_build_array,
> json_build_object, and json_object, nor the aggregate functions json_agg and
> the new json_object_agg. The reason for that is that I have always used
> those for constructing json given to the client, rather than json stored in
> the database, and for such a use there would be no point in turning it into
> jsonb rather than generating the json string directly.
>
> However, I could be persuaded that we should have a jsonb analog of every
> json function. If we decide that, the next question is whether we have to
> have it now, or if it can wait.

my 0.02$: it can wait -- possibly forever. Assuming the casts work I
see absolutely no issue whatsover asking users to do:

select xx_to_json(something complex)::jsonb;

If you examine all the use cases json and jsonb, while they certainly
have some overlap, are going to be used in different patterns. In
hindsight the type bifurcation was a good thing ISTM.

I don't think there should be any expectation for 100% match of the
API especially since you can slide things around with casts. In fact,
for heavy serialization at the end of the day it might be better to
defer the jsonb creation to the final stage of serialization anyways
(avoiding iterative insertion) even if we did match the API.

(can't hurt to manage scope either considering the timelines for 9.4)

merlin

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> In the jsonb patch I have been working on, I have replicated all of what
> I call the json processing functions, and I will shortly add analogs for
> the new functions in that category json_to_record and json_to_recordset.

> However I have not replicated what I call the json generation functions,
> array_to_json, row_to_json, to_json, and the new functions
> json_build_array, json_build_object, and json_object, nor the aggregate
> functions json_agg and the new json_object_agg. The reason for that is
> that I have always used those for constructing json given to the client,
> rather than json stored in the database, and for such a use there would
> be no point in turning it into jsonb rather than generating the json
> string directly.

> However, I could be persuaded that we should have a jsonb analog of
> every json function. If we decide that, the next question is whether we
> have to have it now, or if it can wait.

> (The other notable thing that's missing, and I think can't wait, is
> casts from json to jsonb and vice versa. I'm going to work on that
> immediately.)

It disturbs me that two weeks into CF4, we appear to still be in
full-speed-ahead development mode for jsonb. Every other feature
that's hoping to get into 9.4 is supposed to have a completed patch
under review by the CF process.

If jsonb is an exception, why? It seems to have already gotten a
pass on the matter of documentation quality. I'm reluctant to write
a blank check for more code.

regards, tom lane

On 01/29/2014 10:21 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> In the jsonb patch I have been working on, I have replicated all of what
>> I call the json processing functions, and I will shortly add analogs for
>> the new functions in that category json_to_record and json_to_recordset.
>> However I have not replicated what I call the json generation functions,
>> array_to_json, row_to_json, to_json, and the new functions
>> json_build_array, json_build_object, and json_object, nor the aggregate
>> functions json_agg and the new json_object_agg. The reason for that is
>> that I have always used those for constructing json given to the client,
>> rather than json stored in the database, and for such a use there would
>> be no point in turning it into jsonb rather than generating the json
>> string directly.
>> However, I could be persuaded that we should have a jsonb analog of
>> every json function. If we decide that, the next question is whether we
>> have to have it now, or if it can wait.
>> (The other notable thing that's missing, and I think can't wait, is
>> casts from json to jsonb and vice versa. I'm going to work on that
>> immediately.)
> It disturbs me that two weeks into CF4, we appear to still be in
> full-speed-ahead development mode for jsonb. Every other feature
> that's hoping to get into 9.4 is supposed to have a completed patch
> under review by the CF process.
>
> If jsonb is an exception, why? It seems to have already gotten a
> pass on the matter of documentation quality. I'm reluctant to write
> a blank check for more code.
>

In that case I will add the casts, which are trivial but essential, and
be done. Apart from that there is no essential development work.

FYI, the principal causes of delay have been a) some ill health on my
part and b) Russian vacation season. I've been very conscious that we've
been stretching the deadline a bit.

I am going to change the documentation stuff you griped about, in the
way I previously suggested.

cheers

andrew