On 8/15/10 8:47 PM, Andrew Dunstan wrote:
> On 08/15/2010 11:03 PM, Tom Lane wrote:
>> Charles Pritchard<chuck@jumis.com> writes:
>>> I'd originally sent this to Joseph Adams, as he has been working on
>>> adding a JSON datatype.
>>> I've suggested supporting BSON, as there are many client
>>> implementations
>>> available,
>> I knew there would be a lot of critters crawling out as soon as we
>> turned over this rock. Which other data-formats-of-the-week shall
>> we immortalize as core PG types?
>>
>>
>
> If BSON is simply in effect an efficient encoding of JSON, then it's
> not clear to me that we would want another type at all. Rather, we
> might want to consider storing the data in this supposedly more
> efficient format, and maybe also some conversion routines.
>
> I agree that we don't want in core a huge array of general
> serialization formats. The one thing that JSON has going for it for
> general use, in my view, is that, unlike hstore, the structure is not
> flat. That makes it potentially useful for various purposes,
> especially complex structured function arguments, in places where
> using hstore can be rather limiting, and xml overly verbose.
While I certainly haven't done homework on this -- I agree with Andrew.
Storing internally as BSON (if it holds up to its premise) would mean
more efficient traversal
of internal objects in the future, if we were to have JSON-related
functions/selectors.
The core type would still be json, and would return as text, a json string,
but internally it would be stored as BSON, and a function would be
available,
json_to_bson(typedjsoncol::json), returning a binary string.
