From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Cleaning up ERRCODE usage in our XML code |
Date: | 2024-09-23 17:17:02 |
Message-ID: | 3192216.1727111822@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 20 Sep 2024, at 21:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2024-09-23 18:04:30 | Re: Add llvm version into the version string |
Previous Message | Tomas Vondra | 2024-09-23 16:13:23 | Re: Compress ReorderBuffer spill files using LZ4 |