Re: [PATCH] contrib/xml2: xslt_process() should report XSLT-related error details

And yet again after the changes introduced in
93001888d85c21a5b9ab1fe8dabfecb673fc007c by Tom Lane I had to rebase my
patches (see attachments).

An open question on the 2nd patch remains how to properly expose
xml_parse(). That is, if somebody is interested in merging it at all.
You might want to apply only the first one as well.

Best regards,
Robin Haberkorn

On Mon Jul 7, 2025 at 19:15:52 GMT +03, Robin Haberkorn wrote:
> 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