On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg <p...@pvh.ca> wrote:> > PL/V8 is fast, it's sandboxed, and while it doesn't provide GIN or > GIST operators out of the box, maybe those could be motivated by its > inclusion.
I also feel that a big problem with JSON as a data type is that there is not a powerful, common navigation method. JSON path is basically pretty obscure by comparison to XPath. As a result, the common approach to navigation in a JSON structure is basically "write procedures". And that is only perfectly supported by a full-blown interpreter. So that's why I'm personally more inclined to lend my attention to embedding JavaScript entirely. Not to say there aren't areas ripe for improvement: * It'd be nice to pass intermediate in-memory representations rather than calling JSON.parse all the time, similar to OPAQUE except sound (so bogus pointers cannot be passed). Basically, an "ephemeral type". It could save a lot of when composing operators. I've needed this for other projects, but for much the same reason. * It'd be nice to be able to safely define indexes in a trusted language somehow, writing the penalty and split functions, et al. Right now it's my recollection that defining GiST operators in a naive port to Javascript would give you the power to return garbage that is not merely wrong, but could also crash Postgres if it uses a bogus indexes. Ready and willing to be corrected* * Some kind of partial toasting of large datums (I think Simon Riggs briefly glossed over such an idea when we were talking about this general use case) But nothing I can quickly identify in the Postgres as-is is opposed to any of these improvements at a design level, so they can be chipped off into incremental work in the future. -- fdr * Madness, you say? http://bellard.org/jslinux/, if your browser is new enough. The relevant spec: https://www.khronos.org/registry/typedarray/specs/latest/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
