Re: Cleaning up ERRCODE usage in our XML code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Cleaning up ERRCODE usage in our XML code
Date: 2024-09-24 17:01:04
Message-ID: 3417851.1727197264@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 23 Sep 2024, at 19:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, I looked at that but wasn't sure what to do with it. We should
>> have validated the decl header when the XML value was created, so if
>> we get here then either the value got corrupted on-disk or in-transit,
>> or something forgot to do that validation, or libxml has changed its
>> mind since then about what's a valid decl. At least some of those
>> cases are probably legitimately called INTERNAL_ERROR. I thought for
>> awhile about ERRCODE_DATA_CORRUPTED, but I'm not convinced that's a
>> better fit.

> I agree that it might not be an obvious better fit, but also not an obvious
> worse fit. It will make it easier to filter on during fleet analysis so I
> would be inclined to change it, but the main value of the patch are other hunks
> so feel free to ignore.

Fair enough. Pushed with ERRCODE_DATA_CORRUPTED used there.
Thanks again for reviewing.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2024-09-24 17:22:52 Re: Add new COPY option REJECT_LIMIT
Previous Message Alvaro Herrera 2024-09-24 16:59:46 Re: not null constraints, again