From: | Daniel Farina <daniel(at)heroku(dot)com> |
---|---|
To: | Peter van Hardenberg <pvh(at)pvh(dot)ca> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Subject: | Re: JSON for PG 9.2 |
Date: | 2011-12-13 01:37:13 |
Message-ID: | CAAZKuFas4ViPODFdmf8Uybx3JuS2E+KyLtHjVu=9BWdjxie=CQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg <pvh(at)pvh(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2011-12-13 01:46:41 | Re: JSON for PG 9.2 |
Previous Message | Andrew Dunstan | 2011-12-13 01:36:02 | Re: JSON for PG 9.2 |