From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | contrib/xml2 regression tests vs no-libxslt build option |
Date: | 2010-03-01 15:32:32 |
Message-ID: | 16986.1267457552@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-03-01 15:55:28 | Re: psql with GSS can crash |
Previous Message | Greg Stark | 2010-03-01 15:18:14 | Re: Re: pgsql: add EPERM to the list of return codes to expect from opening |