From: | Laurette Cisneros <laurette(at)nextbus(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg_restore error |
Date: | 2002-09-04 20:15:27 |
Message-ID: | Pine.LNX.4.44.0209041314350.13351-100000@visor.corp.nextbus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
A followup question on this...
What about user create functions (i.e. create function...as '<path>')
can the path have $libdir/ on it as well?
Thanks,
L.
On Tue, 3 Sep 2002, Tom Lane wrote:
> Laurette Cisneros <laurette(at)nextbus(dot)com> writes:
> > I am currently on 7.2.1 and the software location has changed (to
> > /usr/local/pgsql). And, further research shows that the pg_proc shows:
> > This shows /usr/local/pgsql-7.2/lib/plpgsql for the "probin" column.
>
> > How should an update of software be handled as per pg_proc?
>
> The preferred contents of probin are now like
> $libdir/plpgsql
> (the dollar sign is literal text here). As of 7.2 the server will
> substitute a suitable directory name for "$libdir". You probably
> have a database that was reloaded from an old dump without taking
> advantage of this feature --- before 7.2 you could only use an
> absolute path in probin. Now, absolute paths are deprecated for exactly
> the reason that they make version updates hard.
>
> Note the lack of a ".so" in that probin entry, too. This is also
> a recommended new practice in 7.2 --- no reason to put
> platform-dependent assumptions about shared library extensions into
> your dumps.
>
> regards, tom lane
>
--
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
----------------------------------
A wiki we will go...
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-04 21:40:09 | Re: error trying to load plperl... |
Previous Message | Laurette Cisneros | 2002-09-04 19:03:36 | error trying to load plperl... |