Re: Oid registry

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.
>
>