From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: json (b) and null fields |
Date: | 2014-09-29 15:38:52 |
Message-ID: | 20140929153852.GU16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Andrew Dunstan (andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-09-29 15:40:36 | Re: json (b) and null fields |
Previous Message | Robert Haas | 2014-09-29 15:31:46 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |