On 08/13/2012 12:48 PM, Tom Lane wrote:
> There actually was a previous thread about this:
> http://archives.postgresql.org/pgsql-hackers/2012-05/msg00001.php
> Note in particular Andrew's comment:
>
> Second, RFC 4627 is absolutely clear: a valid JSON value can
> only be an object or an array, so this thing about converting
> arbitrary datum values to JSON is a fantasy. If anything, we
> should adjust the JSON input routines to disallow anything else,
> rather than start to output what is not valid JSON.
Thanks for taking a look. That makes sense. I guess these are similar
issues to those the XML type faces, where working with fragments is a
problem. The spec requires a single root element, but you don't always
have that when you're *building* XML, hence the addition of `IS DOCUMENT'.
I was hoping to find a low-impact way to allow SQL-level construction of
more complex JSON objects with correct text escaping, but it sounds like
this isn't the right route. I don't currently see any way to achieve the
kind of on-the-fly building you can do with XML's xmlelement(),
xmlconcat(), xmlforest() etc; nor equivalent to hstore's
hstore(text[],text[]), and I was hoping to improve that.
I have a half-finished JSON object constructor
json_object_from_arrays(text[], json[]) in the same style as
hstore(text[],text[]) . It won't work without the notion of json-typed
scalars, though, as the values of keys could then only be arrays or
objects, which isn't very useful. I can't usefully accept `anyarray' as
a values argument since arrays are of homogeneous type. Accepting text[]
would be a bug-magnet even if there was some kind of `text
json_escape(text)' function.
Would it be reasonable to add a separate json_element type, one that's
binary-equivalent to `json' but not constrained by the requirement to be
an array or object/dict? Or a `jsobject' ?
As for the value_to_json crashing, works for me:
postgres=# SELECT value_to_json(42); value_to_json
--------------- 42
(1 row)
... since datum_to_json is happy to accept anything you throw at it
using output function lookups, and value_to_json its self doesn't care
about the argument type at all. That was all in the regression tests.
Purely so I understand what the correct handling of the anyelement+text
overload would've been: In light of your comments on opr_sanity would
the right approach be to add a second C function like text_to_json that
only accepts 'text' to avoid confusing the sanity check? So the SQL
"value_to_json(anyelement)" would point to the C "value_to_json" and the
SQL "value_to_json(text)" would point to the C "text_to_json" ?
Anyway, clearly the value_to_json approach is out.
--
Craig Ringer