Re: json (b) and null fields - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: json (b) and null fields
Date
Msg-id 20140929153852.GU16422@tamriel.snowman.net
Whole thread Raw
In response to Re: json (b) and null fields  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: json (b) and null fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: json (b) and null fields  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
* Andrew Dunstan (andrew@dunslane.net) wrote:
> That said, doing this as an extension is probably a good way to go,
> as I suggested upthread, since we could then make it available for
> 9.4, rather than making people wait until 9.5.

Two points on this- having it in 9.5 doesn't preclude someone from
extracting it into an extension for 9.4 (indeed, that makes it far more
likely for such an extension to actually happen, imv..), and having it
in core means it's actually generally available and a function which can
be depended upon, which is far from the case for an extension.  Things
are a bit better if it's in contrib, though we'd want to have more than
one function provided in such a contrib extension.

Perhaps there are other functions related to JSON which should go into
such a contrib extension which would make it more worthwhile..  Would
hate to have an extension that ends up being "yeah, to actually use
JSON in PG you have to have this extension" either though.

I realize that can possibly be a "slippery slope", where we end up with
more in core than really belongs there, but this strikes me as a common
enough case that we should cover it.  If I didn't feel it would be a
frequently used capability, I wouldn't have supported adding it in the
first place..
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Stephen Frost
Date:
Subject: Re: json (b) and null fields