Re: PATCH: Implement value_to_json for single-datum conversion

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