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