Re: Cleaning up ERRCODE usage in our XML code
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-09-24T17:01:04Z
Lists: pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes: > On 23 Sep 2024, at 19:17, Tom Lane <tgl@sss.pgh.pa.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
Commits
-
Neaten up our choices of SQLSTATEs for XML-related errors.
- cd838e200880 18.0 landed