Andrew Dunstan <and...@dunslane.net> writes: > On 09/29/2014 03:23 PM, Pavel Stehule wrote: >> It is better than nothing, but it is not nice for JSON due 2x parsing.
> JSON parsing is actually pretty darn fast. Every json (as opposed to > jsonb) function reparses the json. It's true that this is not nearly as > fast as processing jsonb, but I think for this purpose it's probably not > too bad. More to the point, the way to fix any concerns about double parsing is to create row_to_jsonb(), not to plaster a bunch of options on row_to_json(). One of the reasons I didn't like the extra option for row_to_json is that having any such options would inevitably create confusion when we do invent row_to_jsonb, because that will certainly not have a "pretty" option. So row_to_json('...', true) and row_to_jsonb('...', true) would both be accepted but they'd interpret their second arguments entirely differently. This is not really the fault of the "ignore_null_fields" flag, but of the "pretty" flag, which arguably should not have been there in the first place. But looking at that precedent doesn't exactly fill one with confidence that adding more optional arguments to row_to_json isn't going to create even more problems down the line. Breaking it out as a separate function seems to me to be a much better long-term design. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers