On Sun, Dec 18, 2011 at 12:26 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
