Re: Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Hentosh <hentosh(at)io(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)
Date: 2001-05-08 16:07:27
Message-ID: Pine.LNX.4.30.0105081759330.759-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane writes:

> In the long run I think we should abandon the notion that full path
> specifications are the preferred way to locate dynamic libraries.
> It would be a lot better for portability if C function libraries could
> be referred to like this:
>
> create function pltcl_call_handler() returns opaque
> as 'pltcl' language 'C';
>
> where the backend automatically assumes that a relative path is relative
> to $PGLIB. I'd like to see the backend adding the file extension too,
> to avoid platform dependencies (".so" is not universal).

We could have a run-time parameter that sets a path where to look for
modules. Eventually, we might also want to take a look at libtool's
libltdl, the portable interface to dynamic loading, which would do this
and a number of other things for us.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2001-05-08 16:21:52 Re: Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)
Previous Message Vince Vielhaber 2001-05-08 15:19:26 Re: Alter table add column ignores default

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-05-08 16:14:03 Re: Is `#!/bin/sh' configurable?
Previous Message Rod Taylor 2001-05-08 15:55:44 Re: UserLock oddity with Limit