Re: to_json(NULL) should to return JSON null instead NULL - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: to_json(NULL) should to return JSON null instead NULL
Date
Msg-id 55E5517E.9020004@gmail.com
Whole thread Raw
In response to Re: to_json(NULL) should to return JSON null instead NULL  (Andrew Dunstan <andrew@dunslane.net>)
List 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




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Magnus Hagander
Date:
Subject: Re: Information of pg_stat_ssl visible to all users