| From: | David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | jimw(at)kelcomaine(dot)com, pgsql-general <pgsql-general(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Subject: | Re: relocatable binary distribution |
| Date: | 2004-03-06 05:19:59 |
| Message-ID: | 40495F7F.4090903@zara.6.isreserved.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
>>It seems like you could handle all the above with just a shell script wrapper.
>> All three, the library path, socket directory, and data directory can be
>>specified either in environment or on the command line. Where are you getting
>>stuck?
>
> No, we only handle two of the three; library directory is currently
> hard-coded into the server. At the moment that's seeming like a
> mistake. I wonder why it's not a GUC variable (probably postmaster-only
> for security). Peter, do you recall why you didn't migrate that setting
> into GUC?
Yes, $libdir is hardcoded, which is why in my case I'm not using
'$libdir/plruby.so' but using just 'plruby.so' (no absolute path) so
Postgres can look it up with dynamic_library_path. Will this be unsafe?
--
dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-03-06 05:31:07 | Re: relocatable binary distribution |
| Previous Message | Tom Lane | 2004-03-05 23:06:21 | Re: Large table performance and vacuum |