Re: Cleaning up ERRCODE usage in our XML code
От | Daniel Gustafsson |
---|---|
Тема | Re: Cleaning up ERRCODE usage in our XML code |
Дата | |
Msg-id | E9F34559-AA98-4A7E-BAE7-ECC76FB59F65@yesql.se обсуждение исходный текст |
Ответ на | Re: Cleaning up ERRCODE usage in our XML code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Cleaning up ERRCODE usage in our XML code
|
Список | pgsql-hackers |
> On 23 Sep 2024, at 19:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Gustafsson <daniel@yesql.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
В списке pgsql-hackers по дате отправления: