Re: Question on pg_dump
От | Tom Lane |
---|---|
Тема | Re: Question on pg_dump |
Дата | |
Msg-id | 23466.1076359268@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Question on pg_dump (Michael Brusser <michael@synchronicity.com>) |
Ответы |
Re: Question on pg_dump
|
Список | 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 по дате отправления: