Re: Cleaning up ERRCODE usage in our XML code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cleaning up ERRCODE usage in our XML code
Date
Msg-id 3192216.1727111822@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cleaning up ERRCODE usage in our XML code  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Cleaning up ERRCODE usage in our XML code
List pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 20 Sep 2024, at 21:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Per cfbot, rebased over d5622acb3.  No functional changes.

> Looking over these I don't see anything mis-characterized so +1 on going ahead
> with these.  It would be neat if we end up translating xml2 errors into XQuery
> Error SQLSTATEs but this is a clear improvement over what we have until then.

Thanks for looking at it!

> 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: restrict_nonsystem_relation_kind led to regression (kinda)
Next
From: Tom Lane
Date:
Subject: Re: Add llvm version into the version string