Re: [PATCH] contrib/xml2: xslt_process() should report XSLT-related error details
Robin Haberkorn <haberkorn@b1-systems.de>
From: "Robin Haberkorn" <haberkorn@b1-systems.de>
To: <pgsql-hackers@postgresql.org>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Mike Fowler" <mike@mlfowler.com>,
"Pavel Stehule" <pavel.stehule@gmail.com>, "Michael Paquier"
<michael@paquier.xyz>
Date: 2025-07-07T16:15:52Z
Lists: pgsql-hackers
Attachments
- v4-0001-contrib-xml2-xslt_process-now-reports-XSLT-relate.patch (text/x-patch) patch v4-0001
- v4-0002-contrib-xml2-overloaded-xslt_process-to-provide-v.patch (text/x-patch) patch v4-0002
After the changes introduced by Michael Paquier (commited as 732061150b004385810e522f8629f5bf91d977b7) I had to rebase my patches. Among other things pg_xml_error_occurred() was already called except after xsltSaveResultToString(). From what I understand, it's not really necessary to mangle the encoding of the strings that underlie xmltype, so I removed a FIXME comment in the 2nd patch compared to v3. IMHO the PG_XML_STRICTNESS_LEGACY can now also be removed from xpath.c, but I will raise this question in the appropriate thread again. Best regards, Robin Haberkorn On Wed May 7, 2025 at 11:16:37 GMT +03, Robin Haberkorn wrote: > Hello again, > > I did prepare another patch, which introduces an xmltype-based alternative > for xslt_process(). I would really like to put that up for discussion. IMHO > with this patch, xslt_process() should be ready to be adopted into core. > > Unfortunately, it cleanly applies only on top of the error handling patch I > provided in this thread earlier and it wouldn't really make sense to create a > version that applies on top of master. It just touches the same code as the > previous patch, so they necessarily have to be applied in a certain order. So > I am unsure how to go on. > > I attached both patches in question as a series and would suggest to just > update the Commitfest entry. On the other hand, you might well accept the > first patch, but reject the second one. > > Yours sincerely, > Robin Haberkorn > > On Mon Apr 28, 2025 at 14:12:22 GMT +03, Robin Haberkorn wrote: >> On Tue Apr 22, 2025 at 17:47:20 GMT +03, Robin Haberkorn wrote: >>> Perhaps you can tell me what else is preventing adoption into core. I believe >>> that xslt_process() should also accept the `xml` type as an alternative to >>> strings. Strings should be kept for backwards compatibility, though. Also, >>> the stylesheet parameter passing is very crude and limited. I suggest, that >>> the current method of passing them as strings (see parse_params()) is >>> deprecated and we don't try to tackle its limitations, but will instead >>> accept hstores. If you agree, I will work on these two tasks next. >> >> On the other hand, since hstore is a module, it seems we cannot really >> have any other module or core depend on it, correct? >> Perhaps the xmltype-variant of xslt_process() could accept string arrays >> instead. >> -- Robin Haberkorn Software Engineer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix up misuse of "volatile" in contrib/xml2.
- 93001888d85c 19 (unreleased) cited
-
xml2: Improve error handling of libxml2 calls
- 732061150b00 19 (unreleased) cited
-
Rewrite libxml error handling to be more robust.
- cacd42d62cb2 9.2.0 cited