Re: Should the JSON datatype be a specialization of text? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should the JSON datatype be a specialization of text?
Date
Msg-id AANLkTikxGN17BAiPdNWLvu6rlvGz-zrywTo1CMve0wSs@mail.gmail.com
Whole thread Raw
In response to Should the JSON datatype be a specialization of text?  (Joseph Adams <joeyadams3.14159@gmail.com>)
Responses Re: Should the JSON datatype be a specialization of text?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jun 17, 2010 at 2:29 AM, Joseph Adams
<joeyadams3.14159@gmail.com> wrote:
>        * No surprises when casting between JSON and TEXT.  If approach B is
> used, '"string"'::json would be '"string"', but '"string"'::json::text
> would be 'string'.

As far as I'm concerned, that's a non-starter.  It should be legal to
cast text to json, but what it should do is validate that the string
is already legal JSON, not quote it as a string.  I think you'll find
that things get pretty horribly messy pretty fast if you do it any
other way.  What happens if the user has {1,2,3} in a text column
someplace and wants to tread this as a JSON object?

>        * 'null'::json and NULL are distinct.  'null'::json is just a string
> containing 'null' and won't ever become NULL unless you explicitly
> pass it through from_json.  Also, if I'm not mistaken, input functions
> can't yield null when given non-null input (see the above link).

I believe that keeping a JSON NULL separate from an SQL NULL is
absolutely essential.

By the way, how about posting your code and adding it to the
CommitFest page for others to review?  Early feedback is usually good,
where these things are concerned.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Jean-Baptiste Quenot
Date:
Subject: pg_dump does not honor namespaces when functions are used in index
Next
From: Boszormenyi Zoltan
Date:
Subject: ECPG FETCH readahead