Re: Duplicate JSON Object Keys

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Duplicate JSON Object Keys
Date: 2013-03-13 13:09:18
Message-ID: 20130313130918.GA27988@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-03-13 20:48:57 +0800, Craig Ringer wrote:
> On 03/13/2013 08:17 PM, Robert Haas wrote:
> > I think Andrew and I had envisioned this as basically a text data type
> > that enforces some syntax checking on its input, hence the current
> > design. But I'm not sure that's the ONLY sensible design.
> We're probably stuck with it at this point, but it may well be worth
> considering the later introduction of a compatible `jsonobj` that stores
> parsed and normalized json objects in some internal format the client
> doesn't have to care about, like serialized V8 JS VM objects.
>
> I suspect that such a type is better offered by a contrib until/unless
> PL/V8 or a similar becomes a core language. It'd be nuts to try to
> re-implement all of the JSON and javascript object functionality in a
> javascript engine when we can just plug an existing one in and use its
> JSON and javascript object manipulation. The minimalist approach makes
> sense for the json type precisely because it's just validated text, but
> I don't think it makes sense to continually extend it and slowly
> reinvent a whole javascript engine in Pg.

While I am not convinced - but not the contrary either - that using
something like V8 is a good idea, I wish the patch adding json had
reserved the first byte in the varlena for the 'json encoding' or
something similar. That would have left the road open for easily adding
different encodings in the future. Now youre left of marking it with a
nullbyte in the beginning or similar atrocities...

Just wanted to say that we might want to think about such stuff now that
we preserve cross-version compatibility of on-disk data the next time we
add a type.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-03-13 13:13:40 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Previous Message Amit Kapila 2013-03-13 13:08:12 Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]