Skip site navigation (1) Skip section navigation (2)

Re: is JSON really "a type" (Re: data to json enhancements)

From: Darren Duncan <darren(at)darrenduncan(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: is JSON really "a type" (Re: data to json enhancements)
Date: 2012-09-30 06:13:53
Message-ID: 5067E321.3000103@darrenduncan.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Hannu Krosing wrote:
> Reflecting over the dual possible interpretation of what it does mean to 
> convert between "text" and "json" data types it has dawned to me that 
> the confusion may come mainly from wanting json to be two things at once:
> 
> 1. - a serialisation of of a subset of javascript objects to a string.
> 
> 2. - a dynamic type represented by the above serialisation.
> 
> case 1
> ------
> 
> If we stick with interpretation 1. then json datatype is really no more 
> than a domain based on "text" type and having a CHECK is_valid_json() 
> constraint.
<snip>

> case 2
> ------
> 
> My suggestions on using typecasts for convert-to-json were result of 
> this interpretation of json-as-dynamic-type.
> 
> Having thought more of this I now think that we probably should leave 
> JSON alone and develop an separate dynamic type here.
<snip>

I think it would be best to have 2 main JSON-concerning data types:

1. A proper subset of "text" consisting of every value meeting some 
is_valid_json() constraint, as a DOMAIN; every value of this type is a "text".

2. A type that is disjoint from "text", that is, no value of this type would 
compare as equal to any "text" value.  It would be considered a collection type, 
similarly to how an array or tuple or relation is, but having arbitrary depth 
and that is heterogeneous in the general case.

You could say that #1 is to textual source code what #2 is to a parsed syntax 
tree of that code.  Or that #1 is to textual XML what #2 is to an XML DOM.

It would be type #2 above that is the primary JSON type, which has all the 
special operators for working with JSON, while type #1 would be opaque, just a 
character string, and must be cast as type #2 in order to use any special 
operators on it.  Similarly, all the converting operators between other types 
and JSON would be with #2 only, and producing #1 must go through #2.

So call #1 say JSON_source and #2 say JSON_model, or JSON_text and JSON 
respectively.

That's how I think it should work.

-- Darren Duncan


In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2012-09-30 09:26:37
Subject: Question regarding Sync message and unnamed portal
Previous:From: Tatsuo IshiiDate: 2012-09-30 02:38:17
Subject: Re: 64-bit API for large object

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group