From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Chris BSomething <xpusostomos@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18715: replace() function silently fails if 3rd argument is
 null
In-reply-to: 
 <CAKFQuwZ8HCXZF+dFhW809Zuv+Z6AStQ10kkFiYTC-f79d5U1Ug@mail.gmail.com>
References: <18715-7035b5d78571887e@postgresql.org>
 <CAKFQuwaFtdrDPryMUfBy_+DnsrGishCuXHc+doVLjdczhWWP1w@mail.gmail.com>
 <CADrHaBGAgjGCG_d0=myn+Rq1qNSduDA=_f=B8bLRzQm=E-sL4g@mail.gmail.com>
 <CAKFQuwZ8HCXZF+dFhW809Zuv+Z6AStQ10kkFiYTC-f79d5U1Ug@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Tue, 19 Nov 2024 08:30:18 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <3778527.1732034860.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 19 Nov 2024 11:47:40 -0500
Message-ID: <3778528.1732034860@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3778528.1732034860%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, Nov 19, 2024 at 8:08 AM Chris BSomething <xpusostomos@gmail.com>
> wrote:
>> Nowhere (that I can see) does any documentation "define" that replace
>> returns null on null input to arg 3. Nor is it obvious that any "strict"
>> application of any principle should have it return null.

> Fair, I keep forgetting that we don't document the "strict" property of a
> function definition.  Absent that, I agree it's a documentation bug that we
> don't adequately explain the strictness behavior of this function.

I thought we documented somewhere that built-in functions are strict
unless explicitly stated otherwise ... but I sure can't find that
statement right now.

> "Replacing text with null is problematic, but no problem arises if there is
> nothing to be done." - while true I see little desire to make that
> conditionalized behavior reality.  IOW, you are correct, but it also isn't
> likely to change.  The current behavior benefits developers over users, but
> we make up for it by spending time elsewhere.

It's generally true in the SQL standard that functions yield null if
any of their inputs are null.  In some cases you could argue that a
particular input might not be consulted given the values of the other
inputs, but they've steered away from that sort of definitional and
implementation complexity.  And so have we.

			regards, tom lane