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
Senior Software Engineer
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
