From: Tom Lane <tgl@sss.pgh.pa.us>
To: muhlemmer@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15884: json_object_agg errors on null in field name
In-reply-to: <15884-c32d848f787fcae3@postgresql.org>
References: <15884-c32d848f787fcae3@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 02 Jul 2019 15:04:15 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12597.1566935875.1@sss.pgh.pa.us>
Date: Tue, 27 Aug 2019 15:57:55 -0400
Message-ID: <12598.1566935875@sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> According to the documentation on aggregate expressions:
> https://www.postgresql.org/docs/11/sql-expressions.html#SYNTAX-AGGREGATES
> "Most aggregate functions ignore null inputs, so that rows in which one or
> more of the expression(s) yield null are discarded. This can be assumed to
> be true, unless otherwise specified, for all built-in aggregates."

> On aggregate function documentation no specific mention is made for
> json_object_agg().
> https://www.postgresql.org/docs/11/functions-aggregate.html

> However, json_object_agg() throws an error in case of null in the
> argument(s): "error: field name must not be null". And I get it, JSON keys
> need to be unique strings and null is not that. However, this error is also
> thrown if both keys and values are an empty CTE result.

I'm inclined to think this is just a documentation deficiency, ie the
functions-aggregate page needs to mention that the keys input isn't
allowed to be null.

The function does (and should, I think) accept rows that have non-null key
and null value, so that's already a deviation from the "default" aggregate
behavior that should be documented.  And giving a null key with non-null
value probably needs to be an error, because silently ignoring non-null
input doesn't seem nice.  You could make an argument that rows in which
both are null should be silently ignored, but I think that's at best a
judgment call.  While it'd be convenient in some cases, you could get the
same behavior by excluding such rows with a WHERE test.  On the other
side, it's not very orthogonal with the other two cases, and arguably
it could mask mistakes.

Given that it's been working this way since the function was introduced
in 9.4, I'm disinclined to change it now.  I'll go see about improving
the docs, though.

			regards, tom lane