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
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. |
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?) |