Re: BUG #18715: replace() function silently fails if 3rd argument is null
От | Tom Lane |
---|---|
Тема | Re: BUG #18715: replace() function silently fails if 3rd argument is null |
Дата | |
Msg-id | 3778528.1732034860@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18715: replace() function silently fails if 3rd argument is null ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: BUG #18715: replace() function silently fails if 3rd argument is null
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: