Re: JSON in 9.2 - Could we have just one to_json() function instead of two separate versions ?

On Tue, 2012-05-01 at 11:11 -0700, Andrew Dunstan wrote:
> On Tue, May 1, 2012 at 9:56 AM, Joey Adams
> <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
...
> No, the RFC says (emphasis mine):
>
> A JSON *text* is a serialized object or array.
>
> If we let the JSON type correspond to a *value* instead, this
> restriction does not apply, and the JSON type has a useful
> recursive
> definition.
>
> For example, this function would not be possible if we applied
> the
> "object or array" restriction:
>
> unnest(json) returns setof json
>
> Note that a similar distinction appears with the XML type:
> "document"
> versus "content".
>
>
> I think you're playing with words. But in any case, the RFC says this
> regarding generators:
>
> 5. Generators
>
> A JSON generator produces JSON text. The resulting text MUST
> strictly conform to the JSON grammar.

I know it is a weak argument, but at least python, ruby and Javascript
in both Firefox and Chrome do "generate" JSON values, so our users might
kind of expect us to do the same :

Python
---------
hannu(at)hvost:~$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.dumps(1)
'1'

Ruby:
-------
hannu(at)hvost:~$ irb
irb(main):001:0> require 'json'
=> true
irb(main):002:0> JSON.generate(1)
=> "1"

Mozilla Javascript
------------------
>>> JSON.stringify(1) "1"

Chrome Javascript
------------------
> JSON.stringify(1)
"1"

> Our functions do seem to be JSON generators. So even if we accept
> things that aren't JSON texts in our parser (possibly permitted
> by section 4 of the RFC) we should not be generating them.

we could have a function

json_generator(json) returns text

for generating pure JSON texts ;)

the argument for interpreting out json type as "JSON value" instead of
"JSON text" would be much bigger flexibility regarding extension types
support for json (and not only extension types, but also the types
explicitly unsupported by json, like Date) via defining casts to and
from json.

>From http://en.wikipedia.org/wiki/JSON

-------------------------------------------------------------------------
Unsupported native data types
-----------------------------
JavaScript syntax defines several native data types not included in the
JSON standard:[7] Date, Error, Math, Regular Expression, and Function.
These JavaScript data types must be represented as some other data
format, with the programs on both ends agreeing on how to convert
between types. As of 2011, there are some de facto standards for e.g.
converting between Date and String, but none universally
recognized.[8][9] Other languages may have a different set of native
types that must be serialized carefully to deal with this type of
conversion.

-------------------------------------------------------------------------

If we allowed user-defined casts for things like Date the out users
could decide, which de facto standard to support on each specific case .

But if we did interpret out json type strictly as "JSON text", not "JSON
value", this would need another type for json_value.

And it is entirely possible that somebody does want to do what merlin
described recently, that is get a rowset of "json" values from the
client and wrap them in '[' and ']' on way out, it wuld be shame to
restrict his json array elements to be just objects and arrays and not
the other legal json values.

--
-------
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/