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

In response to

Responses

Browse pgsql-hackers by date

  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