Re: proposal: ignore null fields in not relation type composite type based constructors - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: ignore null fields in not relation type composite type based constructors
Date
Msg-id CAFj8pRCBMOO6JURjO=3xEdNq8AcVrVinfAVQebTcg_C=2WZq5A@mail.gmail.com
Whole thread Raw
In response to Re: proposal: ignore null fields in not relation type composite type based constructors  (Stephen Frost <sfrost@snowman.net>)
Responses Re: proposal: ignore null fields in not relation type composite type based constructors
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: pgcrypto: PGP signatures
Next
From: Stephen Frost
Date:
Subject: Re: [BUGS] BUG #10823: Better REINDEX syntax.