| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: additional json functionality |
| Date: | 2013-11-18 04:19:03 |
| Message-ID: | 52899537.5030001@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/17/2013 08:49 PM, Josh Berkus wrote:
>> Now, if it turns out that the new hstore is not dealing with json input
>> and output, we could have json, jstore and hstore.
> Jstore isn't the worst name suggestion I've heard on this thread. The
> reason I prefer JSONB though, is that a new user looking for a place to
> put JSON data will clearly realize that JSON and JSONB are alternatives
> and related in some way. They won't necessarily expect that "jstore"
> has anything to do with JSON, especially when there is another type
> called "JSON". Quite a few people are liable to think it's something to
> do with Java.
>
> Besides, we might get sued by these people: http://www.jstor.org/ ;-)
>
I don't think any name that doesn't begin with "json" is acceptable. I
could live with "jsonb". It has the merit of brevity, but maybe it's a
tad too close to "json" to be the right answer.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2013-11-18 04:21:02 | Re: additional json functionality |
| Previous Message | KONDO Mitsumasa | 2013-11-18 04:07:52 | Re: Optimize kernel readahead using buffer access strategy |