From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | michael(at)synchronicity(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Question on pg_dump |
Date: | 2004-02-09 20:41:08 |
Message-ID: | 23466.1076359268@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Brusser <michael(at)synchronicity(dot)com> writes:
> I'm running Postgres v.7.3.4.
> In my database dump file I see this:
> CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
> AS '/home/tmichael/build/relipg21/syncinc/lib.sol2/plpgsql',
> 'plpgsql_call_handler'
> LANGUAGE c;
> The hardcoded library path may become an obstacle when loading
> data into a different server. Is there a way to avoid this?
The preferred way to write it nowadays is '$libdir/plpgsql', but
you evidently have a legacy value embedded in your pg_proc table.
pg_dump will not second-guess this, and so the old full-path
approach will persist over dump/reloads until you do something about it.
I'd suggest editing the dump file before you reload, or even manually
updating pg_proc.probin for this function entry so that future dumps
are right.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2004-02-09 20:56:30 | Re: Two-phase commit |
Previous Message | Jan Wieck | 2004-02-09 20:41:07 | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |