On Wed, Jan 29, 2014 at 9:08 AM, Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
