Re: Question on pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Question on pg_dump
Date
Msg-id 23466.1076359268@sss.pgh.pa.us
Whole thread Raw
In response to Question on pg_dump  (Michael Brusser <michael@synchronicity.com>)
Responses Re: Question on pg_dump  (Michael Brusser <michael@synchronicity.com>)
List pgsql-hackers
Michael Brusser <michael@synchronicity.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposed Query Planner TODO items
Next
From: Greg Stark
Date:
Subject: Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint