contrib/xml2 regression tests vs no-libxslt build option
От | Tom Lane |
---|---|
Тема | contrib/xml2 regression tests vs no-libxslt build option |
Дата | |
Msg-id | 16986.1267457552@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: contrib/xml2 regression tests vs no-libxslt build
option
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: