From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Cleaning up ERRCODE usage in our XML code |
Date: | 2024-09-24 06:48:06 |
Message-ID: | E9F34559-AA98-4A7E-BAE7-ECC76FB59F65@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 23 Sep 2024, at 19:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Gustafsson <daniel(at)yesql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-09-24 07:03:00 | Re: not null constraints, again |
Previous Message | Masahiko Sawada | 2024-09-24 06:42:15 | Re: Conflict detection for update_deleted in logical replication |