| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | i(dot)portnov(at)compassplus(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19487: Error while executing SQL query involving XML parsing |
| Date: | 2026-09-01 16:21:27 |
| Message-ID: | 1260128.1788279687@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> вс, 30 авг. 2026 г. в 23:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> I've got mixed emotions about back-patching this. It's not really
>> a bug fix, because we already disclaim the safety of relying on
>> CASE for this purpose, cf [1]. I think it might still be reasonable
>> to sneak into v19, but I'm unsure that putting it into 18 is a good
>> idea.
> On back-patching: I share the hesitation about 18. At the same time,
> SQL-language functions with this pattern did work on earlier branches and
> broke for some users after the plan-cache change in 18. I would be fine
> with putting it into 19 and master. If we back-patch to 18, I would treat
> it as a narrow regression fix rather than a semantic promise about CASE.
> Either way works for me.
After thinking about it for a day or so, I elected to push just as far
as 19. While it's true that this fixes the reported problem, it seems
possible that it de-optimizes somebody else's query. People don't
like that in minor releases...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Rachitskiy | 2026-09-01 16:37:12 | Re: BUG #19487: Error while executing SQL query involving XML parsing |
| Previous Message | Fujii Masao | 2026-09-01 02:46:06 | Re: to_char() on integer with V format silently wraps on overflow |