2010/8/25 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Aug 25, 2010 at 1:34 AM, Itagaki Takahiro
> <itagaki.takahiro@gmail.com> wrote:
>> * Should we accept a scalar value as a valid JSON?
>> According to RFC, the root element of JSON text must be an object
>> or array. But to_json() and from_json() accept scalar values.
>
> This seems a bit like the XML document/content distinction, which I've
> never really understood. If [[1], false] is a legal JSON value, then
> it seems odd that [1] should be legal but false not.
I want false to be parsed without error, just for convinience. JSON
specification seems a bit too strict. For example, it doesn't have
date value as its parts, which results in people implement their own
parsing rule for Date(long). And AFAIK the strictness of JSON parsing
is partly because the main platform was browser engines that can
eval() string that causes security issue. Without execution engine, we
can allow more formats than RFC.
>> * On-disk format of JSON values
>> (There might be some discussions before... What is the conclusion?)
>> The current code stores the original input text, but we can use
>> some kinds of pre-parsed format to store JSON, like hstore.
>> It can be different from BSON.
>
> I see no value to choosing a different on-disk format. It might speed
> up indexing, but I/O will be slower.
It depends on use cases, but in my mind plain text will do for us. If
we have JavaScript engine in PostgreSQL like pl/v8 and it handles
on-disk format as-is, then we should choose the kind of format, but in
either text or binary format way it is hopeless to have such
compelling environment in the short future.
Regards,
--
Hitoshi Harada
