Just use $libdir...
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Ramsey
> Sent: Friday, 2 August 2002 4:01 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Module Portability
>
>
> All this talk of mod
Color me embarrased. /
Peter Eisentraut wrote:
>
> Paul Ramsey writes:
>
> > It would be nice if pgsql had a 'default library location'
>
> Sure. That's why it was implemented in 7.2.
>
> --
> Peter Eisentraut [EMAIL PROTECTED]
--
__
/
| Paul Ramsey
| Refractions Re
Paul Ramsey writes:
> It would be nice if pgsql had a 'default library location'
Sure. That's why it was implemented in 7.2.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://a
Correct me if I am wrong (I often am) but isn't MODULE_PATHNAME replaced
by the fully qualified module path during the build process? I mean, the
source code is movable, but a running installed system, with real data,
is not movable, because MODULE_PATHNAME gets mapped to
/usr/local/mypgsql/lib/bl
Contrib modules does have such possibility.
For example:
CREATE FUNCTION ltree_in(opaque)
RETURNS opaque
AS 'MODULE_PATHNAME'
LANGUAGE 'c' with (isstrict);
Oleg
On Thu, 1 Aug 2002, Paul Ramsey wrote:
> All this talk of modularity reminds me of a pet peeve: doing
> dump/restore upgrades
All this talk of modularity reminds me of a pet peeve: doing
dump/restore upgrades when your databases include extension functions is
highly clunky, because extension functions include the fully qualified
path to the linking library. So, for example
create function geometry_in(opaque)
RET
