Skip site navigation (1) Skip section navigation (2)

contrib/xml2 regression tests vs no-libxslt build option

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: (view raw, whole thread or download thread mbox)
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/"
+ psql:pgxml.sql:86: ERROR:  could not find function "xslt_process" in file "/home/pgbuildfarm/workdir/HEAD/inst/lib/postgresql/"
  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 by date

Next:From: Magnus HaganderDate: 2010-03-01 15:55:28
Subject: Re: psql with GSS can crash
Previous:From: Greg StarkDate: 2010-03-01 15:18:14
Subject: Re: Re: pgsql: add EPERM to the list of return codes to expect from opening

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group