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

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 →
  1. Fix up misuse of "volatile" in contrib/xml2.

  2. xml2: Improve error handling of libxml2 calls

  3. Rewrite libxml error handling to be more robust.