Re: Cleaning up ERRCODE usage in our XML code

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-24T06:48:06Z
Lists: pgsql-hackers
> On 23 Sep 2024, at 19:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Daniel Gustafsson <daniel@yesql.se> writes:
> 
>> There is an ERRCODE_INTERNAL_ERROR in xml_out_internal() which seems a tad odd
>> given that any error would be known to be parsing related and b) are caused by
>> libxml and not internally.  Not sure if it's worth bothering with but with the
>> other ones improved it stood out.
> 
> 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.

--
Daniel Gustafsson




Commits

  1. Neaten up our choices of SQLSTATEs for XML-related errors.