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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
