Prev: pgsql: add EPERM to the list of return codes to expect from opening
Next: [HACKERS] USE_LIBXSLT in MSVC builds
From: Tom Lane on 1 Mar 2010 10:32 In yet another demonstration that no good deed goes unpunished, I see that my addition of regression tests to contrib/xml2 is still a few bricks shy of a load. Buildfarm member pika is failing on it, and the reason is clear upon inspection: pika is configured --with-libxml but not --with-libxslt, so the xslt_process calls fail. The obvious thing to do about it is add a variant expected file, but even that won't quite fix things, because of this part of the diff: SET client_min_messages = warning; \set ECHO none + psql:pgxml.sql:79: ERROR: could not find function "xslt_process" in file "/home/pgbuildfarm/workdir/HEAD/inst/lib/postgresql/pgxml.so" + psql:pgxml.sql:86: ERROR: could not find function "xslt_process" in file "/home/pgbuildfarm/workdir/HEAD/inst/lib/postgresql/pgxml.so" RESET client_min_messages; There's no way for a variant file to deal with the installation-specific file path in those messages. I could crank the SET client_min_messages up to PANIC to hide those messages, but that risks losing important information when an unexpected failure happens. So it seems that the only really viable fix is to rearrange the code so that when libxslt isn't available, the xslt_process() function is still defined and available to CREATE FUNCTION; we can make it throw a runtime error instead of just not being present. This seems like a good idea anyway to make the module's ABI more stable: right now, if you dump and restore from an installation with xslt support to one without, or vice versa, you'll have problems with either missing or unloadable SQL function definitions. More work than I had really wanted to spend on xml2, but the alternative is backing out those regression tests :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |