pg_regress: referencing shared objects from tests - Mailing list pgsql-hackers

From Jorgen Austvik - Sun Norway
Subject pg_regress: referencing shared objects from tests
Date
Msg-id 483D4B2E.80203@sun.com
Whole thread Raw
Responses Re: pg_regress: referencing shared objects from tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

we would like to be able to use and ship pg_regress and the PostgreSQL
test suite independently of the PostgreSQL build environment, for
testing and maybe even as a separate package to be build and shipped
with the OS for others to test their setup. Does this sound like a sane
and OK thing to do?

I have a problem with one of the tests (create_function_1.source):

---------8<----------------8<----------------8<----------------8<-------
      20 CREATE FUNCTION int44out(city_budget)
      21    RETURNS cstring
      22    AS '@abs_builddir@/regress@DLSUFFIX@'
      23    LANGUAGE C STRICT;
      24
      25 CREATE FUNCTION check_primary_key ()
      26         RETURNS trigger
      27         AS '@abs_builddir@/../../../contrib/spi/refint@DLSUFFIX@'
      28         LANGUAGE C;
...
      35 CREATE FUNCTION autoinc ()
      36         RETURNS trigger
      37         AS '@abs_builddir@/../../../contrib/spi/autoinc@DLSUFFIX@'
      38         LANGUAGE C;
---------8<----------------8<----------------8<----------------8<-------

(The ../../../contrib/spi-path does not exist outside of the build
environment, so to be able to run the test you need to have source code,
compilers, ...)

I could work around this problem by copying the needed shared objects to
@abs_builddir@ as part of make or make check, I could add a
“–look-for-shared-objects-here” parameter to pg_regress, and you
probably have other suggestions.

Is this something we want to fix, and what would be the right way to do
it? (I have no problem providing a patch.)

-Jørgen
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Group

http://blogs.sun.com/austvik, http://www.autvik.net/

Sun Microsystems AS
Haakon VII gt. 7b
N-7485 Trondheim, Norway


Attachment

pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: [JDBC] How embarrassing: optimization of a one-shot query doesn't work
Next
From: Tom Lane
Date:
Subject: Upcoming back-branch update releases