On 09/02/2011 07:49 PM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 09/02/2011 06:37 PM, Peter Eisentraut wrote:
It won't work, unless you have a solution for fixing the paths of the
shared library modules used by the regression tests.
Well, we could drop those functions and not run tests that require them.
Or we could possibly install the libraries in $libdir and hack pg_proc
accordingly. We'd have to install them on both the source and
destination branches, of course.
The only one that's problematic is pg_regress.so; contrib modules are
already installed in $libdir. I still think that installing
pg_regress.so in $libdir may be the most reasonable solution, assuming
that the delta involved isn't too great. Yeah, we would have to
back-patch the changes into every release branch we want to test
upgrading from, but how risky is that really? The *only* thing it
affects is the regression tests.
Agreed. It doesn't seem terribly dangerous.
There are three listed in the regression db I just looked at:
regress.so, autoinc.so and refint.so.
Maybe I should produce a draft patch for moving pg_regress.so that way,
and we could see how big a delta it really is.
Sounds like a plan.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
