On 08/29/2015 12:02 PM, Pavel Stehule wrote:
2015-08-29 15:43 GMT+02:00 Shulgin, Oleksandr <[email protected] <mailto:[email protected]>>:On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane <[email protected] <mailto:[email protected]>> wrote: Andrew Dunstan <[email protected] <mailto:[email protected]>> writes: > On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: >> Given there were no loud complaints about this, the current behavior >> is appropriate for most users, the rest can still work around using >> coalesce(to_json(...), json 'null'). > I don't think it's necessarily more correct. But I do agree that it's > not a good idea to change the behaviour unless there is major > unhappiness with it. I'm not entirely convinced that JSON NULL and SQL NULL should be treated as the same concept, so I would say that the current behavior is fine --- at least when you think about it in isolation. However, haven't we already bought into that equivalence in these examples? regression=# select row_to_json(row(1,null,2)); row_to_json --------------------------- {"f1":1,"f2":null,"f3":2} (1 row) regression=# select array_to_json(array[1,null,2]); array_to_json --------------- [1,null,2] (1 row) or even in to_json itself: regression=# select to_json(array[1,null,2]); to_json ------------ [1,null,2] (1 row) The scalar case is definitely failing to be consistent with these. Yes, that's my argument for correctness also: to_json() on a composite object should behave like distribution of to_json() calls over object/array elements. Is consistency a sufficient reason to change it? Not for me.It is bug - and it should be fixed. I agree, so this change is too strong for fixing in minor version - but we can change it in unreleased major versions - 9.5 and master.
No, frankly that's being far too free with the word bug. It's not even unambiguously incorrect.
Note that all the to_json functions are strict. In this sense it's quite consistent. If we change it to being called on null input, what should we return if a null non-scalar is passed in?
cheers andrew -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
