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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Hentosh <hentosh(at)io(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)
Date: 2001-05-08 01:22:59
Message-ID: 26130.989284979@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Robert Hentosh <hentosh(at)io(dot)com> writes:
>> If this were to suck in a wrong-version copy of plpgsql.so (and yes,
>> I think 7.1 vs 7.1.1 could be wrong version) then that could cause
>> failures.

> I played with this a little. What would be the proper solution?

At the moment, the solution is to use the createlang script rather than
issuing the commands directly.

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). A function
definition like the above could be dumped and reloaded without fear,
whereas the existing approach is pretty much guaranteed to break
whenever you change machines or install directories.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2001-05-08 01:46:10 Re: interval( 'seconds 27960' ) is broken
Previous Message Tom Lane 2001-05-08 01:08:35 Re: backend dies on 7.1.1 loading large datamodel.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-05-08 01:42:04 Re: create database name with location = 'path';
Previous Message Barry Lind 2001-05-08 01:10:00 Re: [HACKERS] MULTIBYTE and SQL_ASCII (was Re: Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?)