Re: additional json functionality - Mailing list pgsql-hackers

Josh Berkus wrote
> On 11/15/2013 02:59 PM, Merlin Moncure wrote:
>>  On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing <

> hannu@

> > wrote:
>> I think you may be on to something here.  This might also be a way
>> opt-in to fast(er) serialization (upthread it was noted this is
>> unimportant; I'm skeptical).  I deeply feel that two types is not the
>> right path but I'm pretty sure that this can be finessed.
>> 
>>> As far as I understand merlin is mostly ok with stored json being
>>> normalised and the problem is just with constructing "extended"
>>> json (a.k.a. "processing instructions") to be used as source for
>>> specialised parsers and renderers.
> 
> Thing is, I'm not particularly concerned about *Merlin's* specific use
> case, which there are ways around. What I am concerned about is that we
> may have users who have years of data stored in JSON text fields which
> won't survive an upgrade to binary JSON, because we will stop allowing
> certain things (ordering, duplicate keys) which are currently allowed in
> those columns.  At the very least, if we're going to have that kind of
> backwards compatibilty break we'll want to call the new version 10.0.
> 
> That's why naming old JSON as "json_text" won't work; it'll be a
> hardened roadblock to upgrading.

Agreed.  I can't imagine a use-case that would warrant breaking the current
behavior of "json".  Either we live with just one, text-oriented, json type
and "finesse" whatever performance gains we can without breaking
compatibility; or we introduce additional types (I personally like adding 2
instead of one but just adding the binary one would be ok) which - barring
an overwhelming desire by -core to group-self-flagellate - means giving the
new type an as yet unused name.

From a marketing perspective having 3 types with the following properties is
an easy message to sell:

1) json - liberal interpretation w/ validation only; stored as text; output
as-is
2) json_text - strict interpretation w/ validation only; stored as text;
output as-is
3) json_binary - strict interpretation w/ validation & parsing; stored as
binary; output "normalized"

This way "json" seems less like a mistake but rather an intentional desire
to introduce a liberal type that meets data exchange needs in the short term
and now, later, a structured data storage mechanism similar to "hstore".

Even if you have json_binary I can imaging that some people would want to be
able to store the original strict json as-is.  Sure, they can use text, but
this way intent is made clear and validation is attached directly to the
type as opposed to having to be done separately.  The use-cases described
for needing a liberal "json" prove this out.  That said "json" would be an
acceptable replacement for "json_text" in many cases and separate validation
for "strict json" prior to storing into "json" isn't that heinous.

David J.





--
View this message in context:
http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5778655.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.