Re: BUG #19487: Error while executing SQL query involving XML parsing

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

In response to

Responses

Browse pgsql-bugs by date

  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