On Friday 20 July 2001 18:45, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > On to the next batch.... There are a few perl and python scripts shipped
> > as examples -- every last one of them shebangs to '/usr/local/perl' or
> > '/usr/local/python' -- to make them usable, I patch this to
> > '/usr/bin/perl' or python, as appropriate.
> Hmm. Given that they're only examples, and are clearly going to be
> broken until hand-edited on many systems not only RedHat, it's not clear
Well, there were more than just a few at one point. In any case, it's been
awhile since I combed through the example scripts -- of which I only now ship
the one, which is designed to test the perl client -- which I find to be a
useful thing.
> BTW, the only python shebangs I can find in CVS look like
> #! /usr/bin/env python
> Isn't that OK on RedHat?
Yeah, that construct is OK. 7.0.x was different, unless I'm far off-base.
But I'm not shipping any patched python scripts with 7.1.x anyway -- the
6.5.x and 7.0.x dists had some scripts with #!/usr/local/bin/python.
So much for my 'every last one,' eh? :-)
> Much of this could be eliminated given the new path-searching behavior
> for CREATE FUNCTION, I think. Actually I thought Peter had cleaned it
> up already, but I see he hasn't touched the regression tests.
How is this search path defined? Blindly using libdir is not ok --
libdir!=PGLIB, and PGLIB may not be defined in the environment -- it might be
there, but we can't count on it.
> IMHO we
> could have "make installcheck" copy the .so files to $LIBDIR,
libdir!=PGLIB for the RPMs. libdir=/usr/lib; PGLIB=/usr/lib/pgsql. I was so
happy when the bki sources were no longer referenced by PGLIB -- when the
procedural language handlers aren't thusly referenced will be a Happy Day.
If PGLIB could = libdir, and something like PGHANDLER= where the handlers
live, I'd also be happy. If this function search path can be configured to
search in /usr/lib/pgsql and all or any of its subs, while libpq and kin live
in /usr/lib, I _will_ be happy.
> and then
> the regression test input and output files themselves wouldn't need to
> know these paths at all. (OTOH, there'd still be paths in the COPY
> commands. Would it be okay to eliminate testing of backend COPY and
> instead make these regression tests use psql \copy?)
The COPY paths are munged into form by the GNUmakefile patch -- so, if the
GNUmakefile can generally deal with the paths by placing relative paths
(relative to what, though?) in the @abs_srcdir@/@abs_builddir@ substitutions,
then those paths aren't an issue.
Although a psql \copy regression test might be a good thing in its own right.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11