Re: jsonb_set() strictness considered harmful to data

From: raf <raf(at)raf(dot)org>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: jsonb_set() strictness considered harmful to data
Date: 2019-10-20 23:31:15
Message-ID: 20191020233115.jjy6lqd4vsyrdbbo@raf.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Steven Pousty wrote:

> I would think though that raising an exception is better than a
> default behavior which deletes data.

I can't help but feel the need to make the point that
the function is not deleting anything. It is just
returning null. The deletion of data is being performed
by an update statement that uses the function's return
value to set a column value.

I don't agree that raising an exception in the function
is a good idea (perhaps unless it's valid to assume
that this function will only ever be used in such a
context). Making the column not null (as already
suggested) and having the update statement itself raise
the exception seems more appropriate if an exception is
desirable. But that presumes an accurate understanding
of the behaviour of jsonb_set.

Really, I think the best fix would be in the
documentation so that everyone who finds the function
in the documentation understands its behaviour
immediately. I didn't even know there was such a thing
as a strict function or what it means and the
documentation for jsonb_set doesn't mention that it is
a strict function and the examples of its use don't
demonstrate this behaviour. I'm referring to
https://www.postgresql.org/docs/9.5/functions-json.html.

All of this contributes to the astonishment encountered
here. Least astonishment can probably be achieved with
additional documentation but it has to be where the
reader is looking when they first encounter the
function in the documentation so that their
expectations are set correctly and set early. And
documentation can be "fixed" sooner than postgresql 13.

Perhaps an audit of the documentation for all strict
functions would be a good idea to see if they need
work. Knowing that a function won't be executed at all
and will effectively return null when given a null
argument might be important to know for other functions
as well.

cheers,
raf

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message rob stone 2019-10-21 01:18:23 Re: jsonb_set() strictness considered harmful to data
Previous Message Andrew Dunstan 2019-10-20 22:51:05 Re: jsonb_set() strictness considered harmful to data

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-10-20 23:36:39 Re: configure fails for perl check on CentOS8
Previous Message Thomas Munro 2019-10-20 23:21:52 Re: Tweaking DSM and DSA limits