This involves modifying the module to have a stable ABI, that is, the
xslt_process() function still exists even without libxslt. It throws a
runtime error if called, but doesn't prevent executing the CREATE FUNCTION
call. This is a good thing anyway to simplify cross-version upgrades.
These are unnecessary and probably dangerous. I don't see any immediate
risk situations in the core XML support or contrib/xml2 itself, but there
could be issues with external uses of libxml2, and in any case it's an
accident waiting to happen.
Prior to 8.3, these changes are not critical for compatibility with core
Postgres, since core had no libxml2 calls then. However there is still
a risk if contrib/xml2 is used along with libxml2 functionality in Perl
or other loadable modules. So back-patch to all versions.
Also back-patch addition of regression tests. I'm not sure how many of
the cases are interesting without the interaction with core xml code,
but a silly regression test is still better than none at all.
last pair of parameter name/value strings, even when there are MAXPARAMS
of them. Aboriginal bug in contrib/xml2, noted while studying bug #4912
(though I'm not sure whether there's something else involved in that
report).
This might be thought a security issue, since it's a potential backend
crash; but considering that untrustworthy users shouldn't be allowed
to get their hands on xslt_process() anyway, it's probably not worth
getting excited about.
