shihao zhong <[email protected]> writes:
> v2 does that, with a narrower test for the copy. Removing null pairs
> from the state is harmless unless unique_keys is also set, since the
> dedup loop skips nulls before it looks for duplicates. So 0001 copies
> the pairs only for jsonb_object_agg_unique_strict.
Right. That's good, because it pretty much resolves my concern about
the cost of repeated de-duplication. There's no win to be had there
for the jsonb_object_agg_unique variants, since they'd throw error
as soon as they see a duplicate key anyway; hence there will never
be anything that could be removed.
> @@ -404,6 +404,9 @@
> are coerced to text; value arguments are converted as per
> <function>to_json</function> or <function>to_jsonb</function>.
> Values can be null, but keys cannot.
> + If a key appears more than once, the <type>json</type> result keeps
> + every pair, while the <type>jsonb</type> result keeps only the last
> + value for that key.
> </para></entry>
> <entry>No</entry>
> </row>
Indeed :-(. I kind of wonder why we don't regard that as a bug.
However, I suppose the JSON type doesn't enforce no-duplicate-keys
in the first place, so maybe there's an excuse for it.
Anyway, pushed it all with some minor editorialization. Thanks
again for the report and patch!
regards, tom lane