Re: to_json(NULL) should to return JSON null instead NULL

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: to_json(NULL) should to return JSON null instead NULL
Date: 2015-09-01 07:19:26
Message-ID: 55E5517E.9020004@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30/08/15 04:57, Andrew Dunstan wrote:
>
>
> On 08/29/2015 04:27 PM, Tom Lane wrote:

>> I'm not necessarily against changing it --- but it doesn't seem entirely
>> black-and-white to me, and we do now have a couple of versions worth
>> of precedent we'd be breaking with.
>>
>> If we do vote to change it, I'd want to do so now (ie in 9.5) rather than
>> create yet another year's worth of precedent.
>>
>>
>
> I agree with pretty much all of this. My fairly strong inclination is to
> leave it as it is and document the behaviour more clearly. Changing it
> seems likely to introduce a different inconsistency which is harder to
> understand.

This thread reminds me of the decision we had to make when implementing
ISO healthcare datatypes with its own NullFlavors in PostgreSQL, see
section 3.2 of http://arxiv.org/pdf/1003.3370v1.pdf for a discussion.

TLDR: even though semantically there might be overlap in the two kinds
of nulls, there are two mechanisms to represent 'value at present
unknown': in the heaptuple and in the datatype varlena Datum storage,
each with their own IS NULL / STRICT vs isnull and other functions. We
decided that trying to merge both null representing mechanisms would
probably lead to an incomplete merge, and thus many unexpected problems,
and that therefore a clean separation would be easiest to explain and
work with.

regards,
Yeb Havinga

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2015-09-01 07:46:23 Re: Information of pg_stat_ssl visible to all users
Previous Message Amit Kapila 2015-09-01 06:51:43 Re: checkpointer continuous flushing