Hannu Krosing wrote:
Reflecting over the dual possible interpretation of what it does mean to
convert between "text" and "json" data types it has dawned to me that
the confusion may come mainly from wanting json to be two things at once:
1. - a serialisation of of a subset of javascript objects to a string.
2. - a dynamic type represented by the above serialisation.
case 1
------
If we stick with interpretation 1. then json datatype is really no more
than a domain based on "text" type and having a CHECK is_valid_json()
constraint.
<snip>
case 2
------
My suggestions on using typecasts for convert-to-json were result of
this interpretation of json-as-dynamic-type.
Having thought more of this I now think that we probably should leave
JSON alone and develop an separate dynamic type here.
<snip>
I think it would be best to have 2 main JSON-concerning data types:
1. A proper subset of "text" consisting of every value meeting some
is_valid_json() constraint, as a DOMAIN; every value of this type is a "text".
2. A type that is disjoint from "text", that is, no value of this type would
compare as equal to any "text" value. It would be considered a collection type,
similarly to how an array or tuple or relation is, but having arbitrary depth
and that is heterogeneous in the general case.
You could say that #1 is to textual source code what #2 is to a parsed syntax
tree of that code. Or that #1 is to textual XML what #2 is to an XML DOM.
It would be type #2 above that is the primary JSON type, which has all the
special operators for working with JSON, while type #1 would be opaque, just a
character string, and must be cast as type #2 in order to use any special
operators on it. Similarly, all the converting operators between other types
and JSON would be with #2 only, and producing #1 must go through #2.
So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON
respectively.
That's how I think it should work.
-- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
