We can't "./configure PostgreSQL with the right install target options
for the final destination system" because we have limited control over
where our application will be installed. We hack postgres, too, after we
createlang pgsql by updating the pg_catalog.pg_proc table to strip the
"$libdir" from the probin field. There might well be a better way, but
it's what we figured out would let us install our application (including
postgres) in any random spot.

I tested an early version of 8.0 and the dependency on the initial
.configure target seems to have been removed, and I was able to move my
postgres installation without any fiddling. 

- DAP

>-----Original Message-----
>From: Jan Wieck [mailto:JanWieck at Yahoo.com] 
>Sent: Monday, October 11, 2004 9:32 AM
>To: David Parker
>Cc: hannu at skype.net; Slony Mailing List
>Subject: Re: [Slony1-general] external function libraries on 
>non-build machine
>
>On 10/10/2004 11:47 AM, David Parker wrote:
>
>> Thanks for the reply. The situation is a little bit more complicated 
>> in that we are bundling up postgres and slony and installing 
>binaries 
>> onto a "clean" Solaris system.
>> 
>> The following changes got this working for me:
>> 
>>    1) removed references to $libdir in slonik/dbutil.c (test LOAD 
>> commands for the two libraries)
>
>This all strikes me as a workaround for something that is 
>generally broken in the way your deployment works. If your 
>backend cannot load shared extensions via $libdir reference, 
>how does PL/pgSQL work on that system? How is the language 
>handler defined in pg_proc there?
>
>If you would ./configure PostgreSQL with the right install 
>target options for the final destination system, none of all 
>this would be necessary.
>
>
>Jan
>
>>    2) removed references to PGSHARE in slonik/slonik.c, and replaced 
>> with a getenv() on an
>>       environment variable we always have defined in our environment
>>    3) removed references to $libdir in slony1_funcs.sql and 
>> xxid.v74.sql, e.g. changed '$libdir/xxid'
>>       to just 'xxid'
>> 
>> Thanks.
>> 
>> - DAP
>> 
>>>-----Original Message-----
>>>From: hannu at skype.net [mailto:hannu at skype.net]
>>>Sent: Sunday, October 10, 2004 4:06 AM
>>>To: David Parker
>>>Cc: Slony Mailing List; pgsql-general at postgresql.org
>>>Subject: Re: [Slony1-general] external function libraries on 
>non-build 
>>>machine
>>>
>>>> I have built slony 1.0.2 with postgres 7.4.5. This needs to be 
>>>> deployed on a system other than the one on which is was built.
>>>> Somebody on our team had earlier gotten around the problem of not 
>>>> being able to move a postgres install by manually updating the 
>>>> pg_catalog.pg_proc table. But it seems like this worked 
>*after* the 
>>>> procs calling external libraries were installed. With the
>>>slony stuff
>>>> I can't install the procs until the database has been
>>>deployed on its
>>>> target machine, so that hack doesn't seem to help me.
>>>>
>>>> Now I'm trying to run a slonik script on the new system, and I am 
>>>> getting the following error, which I assume is because $libdir no 
>>>> longer references the build file system:
>>>>
>>>> <stdin>:3: Initializing the cluster
>>>> <stdin>:5: PGRES_FATAL_ERROR load '$libdir/xxid';  - ERROR:  
>>>could not
>>>> access file "$libdir/xxid": No such file or directory
>>>
>>>You have to copy the xxid.so and slony1_funcs.so files to where 
>>>postgres extensions live on your target machine. on debian 
>this seems 
>>>to be /usr/lib/postgres/lib/
>>>
>>>this is the same place where you can find various pl implementations 
>>>find /usr/lib -name plpgsql.so should show you the place
>>>
>>>------------
>>>Hannu
>>>
>>>
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at gborg.postgresql.org
>> http://gborg.postgresql.org/mailman/listinfo/slony1-general
>
>
>--
>#==============================================================
>========#
># It's easier to get forgiveness for being wrong than for 
>being right. #
># Let's break this rule - forgive me.                          
>        #
>#================================================== 
>JanWieck at Yahoo.com #
>