Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
От | Hitoshi Harada |
---|---|
Тема | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Дата | |
Msg-id | AANLkTim_0jwnVEtgsDnT+meKqZfZFCtyMLRa8Uzc=tCP@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) (Terry Laurenzo <tj@laurenzo.org>) |
Ответы |
Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
|
Список | pgsql-hackers |
2010/10/17 Terry Laurenzo <tj@laurenzo.org>: > Hi all - > I independently started some work on a similar capability as was contributed > back in August by Joey Adams for a json datatype. Before starting, I did a > quick search but for some reason didn't turn this existing thread up. > What I've been working on is out on github for > now: http://github.com/tlaurenzo/pgjson > When I started, I was actually aiming for something else, and got caught up > going down this rabbit hole. I took a different design approach, making the > internal form be an extended BSON stream and implementing event-driven > parsing and serializing to the different formats. There was some discussion > in the original thread around storing plain text vs a custom format. I have > to admit I've been back and forth a couple of times on this and have come to > like a BSON-like format for the data at rest. Reading your proposal, I'm now +1 for BSON-like style. Especially JS engine's capabilities to map external data to the language representation are good news. I agree the mapping is engine's task, not data format task. I'm not sure if your BSON-like format is more efficient in terms of space and time than plain text, though. I like as simple design as we can accept. ISTM format, I/O interface, simple get/set, mapping tuple from/to object, and indexing are minimum requirement. Something like JSONPath, aggregates, hstore conversion and whatsoever sound too much. Regards, -- Hitoshi Harada
В списке pgsql-hackers по дате отправления: