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
