On 09/26/2012 12:06 AM, Peter Eisentraut wrote:
> On 9/25/12 5:58 PM, Tom Lane wrote:
>> Yes ... but I really don't want to go down the path of treating those as
>> new type properties; it doesn't scale. (And please don't tell me that
>> JSON is the last word in container types and there will never be
>> requests for any more of these.)
> Yeah, I didn't like that part either, but we only add one every five
> years or so.
>
>> Can we define these functions as being the cast-from-foo-to-json and
>> cast-from-foo-to-xml functions? That would let us use the existing cast
>> infrastructure to manage them.
> Sounds attractive, but there might be some problems in the details. For
> example, you can't cast scalar values to valid json values, because a
> valid json value can only be a dictionary or an array.
Nope. Json _value_ can be anything you put in these dicts or arrays.
It was just definition about something called "a json generator" which
was defined to return an array or object/dict
and the json type already can hold all the scalar values, the input
conversion functions happily accept these and generate corresponding
json values.
It was all hashed through when I woke up on this too late in the 9.2 dev
cycle and proposed all the CAST and to_json functions and also a single
to_json for any json generation instead of array_to_json and row_to_json.
so currently we do and we don't have this "json is an array or dict"
functionality
we cant convert anything else directly to json using a to_json function,
but we can do it through input/output functions
and thus we can output scalar-valued json values :
jt=# select '1'::json,'"1"'::json; json | json
------+------ 1 | "1"
(1 row)
IIRC it was something about the to_json functions being generators and
type io functions not being that :P
> If we had a flag
> of some kind saying "cast from foo to json, but only when part of a
> larger json serialization, not by itself", then it might work.
>
>
