Andrew Dunstan <andrew@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
