Re: proposal: ignore null fields in not relation type composite type based constructors
| От | Pavel Stehule |
|---|---|
| Тема | Re: proposal: ignore null fields in not relation type composite type based constructors |
| Дата | |
| Msg-id | CAFj8pRCBMOO6JURjO=3xEdNq8AcVrVinfAVQebTcg_C=2WZq5A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: ignore null fields in not relation type composite type based constructors (Stephen Frost <sfrost@snowman.net>) |
| Ответы |
Re: proposal: ignore null fields in not relation type composite type
based constructors
|
| Список | pgsql-hackers |
Hi
2014-09-08 5:48 GMT+02:00 Stephen Frost <sfrost@snowman.net>:
Pavel, All,
* Pavel Stehule (pavel.stehule@gmail.com) wrote:
> Thank you
I made a few minor adjustments, but the bigger issue (in my view) is
what to do about array_to_json_pretty- seems like we should do the same
there, no? Perhaps you could propose a new patch which incorporates my
minor changes and also removes array_to_json_pretty and makes
array_to_json take an optional argument?
I though about it, and I am not sure. If somebody uses arrays as set, then it can be good idea, when it is used as array, then you cannot to throw a nulls from array.
I am thinking, so it is not necessary, because we can remove NULLs from array simply via iteration over array (what is impossible for row fields)
CREATE OR REPLACE FUNCTION remove_null(anyarray)
RETURNS anyarray AS $$
SELECT ARRAY(SELECT a FROM unnest($1) g(a) WHERE a IS NOT NULL)
$$ LANGUAGE plpgsql;
or this function can be in core for general usage.
ignore_nulls in array_to_json_pretty probably is not necessary. On second hand, the cost is zero, and we can have it for API consistency.
Regards
Pavel
Thoughts?
Thanks,
Stephen
В списке pgsql-hackers по дате отправления: