On Feb 27, 2014, at 3:54 AM, Robert Haas <robertmh...@gmail.com> wrote:
> It's not very clear to me why we think it's a good idea to share the > tree-ish representation between json and hstore. In deference to your > comments that this has been very publicly discussed over quite a > considerable period, I went back and tried to find the email in which > the drivers for that design decision were laid out. I can find no > such email; in fact, the first actual nested hstore patch I can find > is from January 13th and the first jsonb patch I can find is from > February 9th. Neither contains anything much more than the patch > itself, without anything at all describing the design, let alone > explaining why it was chosen. And although there are earlier mentions > of both nested hstore and jsonb, there's nothing that says, OK, this > is why we're doing it that way. Or if there is, I couldn't find it. FWIW, It was discussed quite a bit in meatspace, at the PGCon unconference last spring. > Unless I've missed some emails sent earlier than the dates noted > above, which is possible, the comments by myself and others on this > thread ought to be regarded as timely review. The basic problem here > is that this patch wasn't timely submitted, still doesn't seem to be > very done, and it's getting rather late. The hstore patch landed in the Nov/Dec patch fest, sent to the list on Nov 12. The discussion that led to the decision to implement jsonb was carried out for the week after that. Here’s the thread: http://www.postgresql.org/message-id/528274f3.3060...@sigaev.ru There was also quite a bit of discussion that week in the “additional json functionality” thread. http://www.postgresql.org/message-id/528274d0.7070...@dunslane.net I submitted a review of hstore2, adding documentation, on Dec 20. Andrew got the patch updated with jsonb type, per discussion, and based on a first cut by Teodor, in January, I forget when. v7 was sent to the list on Jan 29. So while some stuff has been added a bit late, it was based on discussion and the example of hstore's code. I think you might have missed quite a bit of the earlier discussion because it was in an hstore thread, not a JSON or JSONB thread. > We therefore face the usual > problem of deciding whether to commit something that we might regret > later. If jsonb turns out to the wrong solution to the json problem, > will there be community support for adding a jsonc type next year? I > bet not. Bit of a red herring, that. You could make that argument about just about *any* data type. I realize it's more loaded for object data types, but personally I have a hard time imagining something other than a text-based type or a binary type. There was disagreement as to whether the binary type should replace the text type, and the consensus of the discussion was to have both. (And then we had 10,000 messages bike-sheadding the name of the binary type, naturally.) > You may think this is most definitely the right direction to > go and you may even be right, but our ability to maneuver and back out > of things goes down to nearly zero once a release goes out the door, > so I think it's entirely appropriate to question whether we're > charting the best possible course. But I certainly understand the > annoyance. Like the hstore type, the jsonb type has a version bit, so if we decide to change its representation to make it more efficient in the future, we will be able to do so without having to introduce a new type. Maybe someday we will want a completely different JSON implementation based on genetic mappings or quantum superpositions or something, but I would not hold up the ability to improve the speed of accessing values, let alone full path indexing via GIN indexing, because we might want to do something different in the future. Besides, hstore has proved itself pretty well over time, so I think it’s pretty safe to adopt its implementation to make an awesome jsonb type. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
