Re: BUG #18715: replace() function silently fails if 3rd argument is null

From: Erik Wienhold <ewie(at)ewie(dot)name>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Chris BSomething <xpusostomos(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18715: replace() function silently fails if 3rd argument is null
Date: 2024-11-19 22:34:23
Message-ID: c4804767-5c7e-4103-9d1e-0c6c2e3433d3@ewie.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 2024-11-19 17:47 +0100, Tom Lane wrote:
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Tue, Nov 19, 2024 at 8:08 AM Chris BSomething <xpusostomos(at)gmail(dot)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.

Perhaps this one?:
> (Most internal functions expect to be declared “strict”.)
https://www.postgresql.org/docs/current/xfunc-internal.html

--
Erik

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-11-19 22:40:48 Re: BUG #18715: replace() function silently fails if 3rd argument is null
Previous Message Tom Lane 2024-11-19 19:33:27 Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails