Re: json (b) and null fields
От | Pavel Stehule |
---|---|
Тема | Re: json (b) and null fields |
Дата | |
Msg-id | CAFj8pRB6W5UkoX8wxOcxyf0TrLj4jtvSq2cN5CmFS9kgAukEqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: json (b) and null fields (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
2014-09-28 18:35 GMT+02:00 Andrew Dunstan <andrew@dunslane.net>:
On 09/27/2014 11:58 PM, Stephen Frost wrote:All,
On Saturday, September 27, 2014, Andrew Dunstan <andrew@dunslane.net <mailto:andrew@dunslane.net>> wrote:
On 09/27/2014 10:52 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 09/27/2014 06:27 PM, Tom Lane wrote:
So my vote is for a separate function and no optional
arguments.
You mean like row_to_json_no_nulls() and json_agg_no_nulls()?
I thought you were proposing that we should revert the
committed patch
lock-stock-n-barrel, and instead invent json_strip_null_fields().
That's instead, not in addition to. Even if you weren't
saying that
exactly, that's where my vote goes.
I was just exploring alternatives. But I think that's where my
vote goes too.
I'm fine with that. I'd like the strip-Nulls capability, but seems like it'd be better off as an independent function (or functions) instead.
Unlike the row_to_json stuff, json{b}_strip_null_fields() can almost certainly be done as a small extension. One advantage of that is that it would be used with 9.4.
In other mail you wrote, how much important is this functionality for JSON, so I don't think so a movement to contrib is a good idea.
We can implement all described functionality in separate function, but it should be in core probably. It is not my idea. I was asked about this functionality by some PostgreSQL 9.4 early users and testers on Czech mailing list.
Regards
Pavel
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: