From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should the JSON datatype be a specialization of text? |
Date: | 2010-06-17 11:34:40 |
Message-ID: | AANLkTikxGN17BAiPdNWLvu6rlvGz-zrywTo1CMve0wSs@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 17, 2010 at 2:29 AM, Joseph Adams
<joeyadams3(dot)14159(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2010-06-17 12:09:47 | ECPG FETCH readahead |
Previous Message | Jean-Baptiste Quenot | 2010-06-17 11:31:53 | pg_dump does not honor namespaces when functions are used in index |