On 09/27/2014 06:27 PM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 09/27/2014 08:00 AM, Stephen Frost wrote:
Yeah, I don't see adding this option to all json generator functions as
making a lot of sense but rather just to the select few things which it
really makes sense for and then having a function which can be used by
users to do the same for results from other operations.
I guess I'm questioning the wisdom of keeping it for row_to_json given
that it doesn't operate recursively anyway (and making it do so would be
difficult and ugly).
IMO, adding it to row_to_json was really ugly to start with, independently
of whether it's difficult or not. That function had one too many optional
arguments already, and in its current form it's nothing but a loaded gun
pointed at users' feet. (Quick, which bool argument is which?)
If we're going to keep this, I think we also need to provide it
(non-recursive) for json_agg via an optional second argument. This
should be a fairly simple change: just steer the result via
composite_to_json if it's a record, rather than to datum_to_json.
Unfortunately, any such thing will fall foul of an established project
policy. I quote the opr_sanity regression test that will complain:
-- Check that there are not aggregates with the same name and different
-- numbers of arguments. While not technically wrong, we have a project policy
-- to avoid this because it opens the door for confusion in connection with
-- ORDER BY: novices frequently put the ORDER BY in the wrong place.
-- See the fate of the single-argument form of string_agg() for history.
So my vote is for a separate function and no optional arguments.
You mean like row_to_json_no_nulls() and json_agg_no_nulls()?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
