| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | 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 13:07:43 |
| Message-ID: | CAKFQuwaFtdrDPryMUfBy_+DnsrGishCuXHc+doVLjdczhWWP1w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Nov 19, 2024 at 5:52 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18715
> Logged by: Chris
> Email address: xpusostomos(at)gmail(dot)com
> PostgreSQL version: 16.5
> Operating system: Linux
> Description:
>
> OK, but now imagine that at runtime the 3rd argument is null... and we
> expect it to be null because that variable is not used in that tuple:
> replace('abcdef', '${m}', null) => null
>
This is not a bug. Replace is defined to return null on null input (i.e.,
strict) and that is the behavior you are seeing.
Use Coalesce to convert your null into an empty string.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2024-11-19 13:10:02 | Re: BUG #18635: " $libdir/adminpack could not be loaded" error with pg_upgrade to PostgreSQL17 |
| Previous Message | Tender Wang | 2024-11-19 09:57:09 | Re: BUG #18371: There are wrong constraint residues when detach hash partiton concurrently |