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  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: pgcrypto: PGP signatures
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [BUGS] BUG #10823: Better REINDEX syntax.