On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
>
>
>
> I am not opposed to making a new type, but I really don't think that
> means we need to do nothing for the existing data type. The suggested
> SERIALIZATION mechanism seems to be fairly intrusive and heavy handed,
> as opposed to the very lightweight mechanism that is Tom's option 3.
Agreed this would be the simplest one. I prefer it to be called
something like "json_embedded?string" to better convey it's use as it is
needed only when converting a postgresql string type to json string
type. json_value already has a standard-defined meaning and is a
supertype of json (which unfortunately is called "json text".
> Personally I don't have a strong feeling about a general to_json
> function, but it's something other people have asked for. The things I
> do care about are the json_agg function (to which nobody has objected)
Not just objected but i am very much for it. +1 from me.
> and finding a mechanism for reasonably converting structured types,
> particularly hstore, to json.
hstore to json is what started this discussion and using
to_json(<sometype>) function was one of the proposed solutions for this.
Using the same mechanism for enabling users to also have custom
serialisations for thins that the standard leaves open - like datetime -
is an added bonus.
> I still think Tom's suggestion is the best and simplest way to do that.
which Toms suggestion you mean here ?
The 3. mentioned above was for making possible 2 separate ways to
convert (serialise/quote/escape and parse/check-for-valid-json) string
to json and afair not about hstore to json.
I'm also looking forward for an easy way or two to populate a record
from json and extract an array from json.
>
> cheers
>
> andrew
