Re: BUG #15884: json_object_agg errors on null in field name
От | Tom Lane |
---|---|
Тема | Re: BUG #15884: json_object_agg errors on null in field name |
Дата | |
Msg-id | 12598.1566935875@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #15884: json_object_agg errors on null in field name (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: