2010/1/4 David E. Wheeler <da...@kineticode.com>:
> On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
>
>> We allow composites as fields. The biggest mismatch in the type model is
>> probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
>> AIUI.
>
> Cool, that sounds right.
Does it mean you should create composite type to create anonymous JSON?
>> OK, but hstores are flat, unlike JSON. We need some way to do the equivalent
>> of xpath along the child axis and without predicate tests. hstore has no
>> real equivalent because it has no nesting.
>
> You mean so that you can fetch a nested value? Hrm. I agree that it's have to
> be XPath like. But perhaps we can use a JavaScript-y syntax for it? There
> could be an operator that returns records:
>
> % SELECT '{"foo":{"bar":["a","b","c"]}}' -> '["foo"]';
> bar
> -------------
> ("{a,b,c}")
>
> % SELECT '{"foo":{"bar":["a","b","c"]}}' -> '["foo"][1]';
> 1
> -----
> (b)
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT ('{"foo":{"bar":["a","b","c"]}}' -> '["foo"][1]')::text;
1
-----
b
Regards,
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
