Re: JSON for PG 9.2

Merlin Moncure <mmoncure@gmail.com>

From: Merlin Moncure <mmoncure@gmail.com>
To: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Cc: Andrew Dunstan <andrew@dunslane.net>, Magnus Hagander <magnus@hagander.net>, Jan Urbański <wulczer@wulczer.org>, Robert Haas <robertmhaas@gmail.com>, "David E. Wheeler" <david@kineticode.com>, Simon Riggs <simon@2ndquadrant.com>, Joey Adams <joeyadams3.14159@gmail.com>, Bruce Momjian <bruce@momjian.us>, Claes Jakobsson <claes@gluefinance.com>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>, Jan Wieck <janwieck@yahoo.com>
Date: 2011-12-19T04:41:54Z
Lists: pgsql-hackers
On Sun, Dec 18, 2011 at 12:26 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>>> Why would that matter more for JSON than for any other non-core type?
>>
>> well, it's a minor headache for all the oid-isn't-in-pgtypes.h types,
>> and only then for high traffic types (which presumably json will be).
>
> Extensions are going to be more and more used and “pervasive” in next
> years, and binary wire transfers is a good goal.  What about creating
> something like the PostgreSQL types IANA?
>
> New type authors would register their OID and as a benefit would get
> listed on some public reference sheet, and we could add some mechanism
> so that default CREATE TYPE calls will not use reserved OID numbers.
>
> Then it would be all cooperative only, so not a security thing, just a
> way to ease binary and extension co-existence.

I think that's a fabulous idea,although we're drifting off the stated
topic here.


Getting back on point, I'm curious about your statement: "without
writing a single line of C".  I took a look at the pl/scheme docs and
was pretty impressed -- what exactly would be involved to get a
guile-based ECMAscript working over the pl/scheme implementation?  How
would that interact exactly with the stated topic -- JSON support?  Do
you even need a json type if you have strong library based parsing and
composition features?

merlin