Re: Sometimes pg_dump generates dump which is not restorable - Mailing list pgsql-hackers

From Dmitry Koterov
Subject Re: Sometimes pg_dump generates dump which is not restorable
Date
Msg-id d7df81620811150204l23485fc3gc86269ee93092bf7@mail.gmail.com
Whole thread Raw
In response to Re: Sometimes pg_dump generates dump which is not restorable  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Oh, I understood you. Clearly, to surely avoid any side-effect in pg_dump, all IMMUTABLE functions must implicitly assign search_path in develop time. It's not obvious, so I propose to include this in CONSTRAINT ... CHECK and CREATE INDEX documentation. :-) Or - raise NOTICE if an IMMUTABLE function is used in CHECK or INDEX, but does not define search_path ints arguments.

Thanks!


On Fri, Nov 14, 2008 at 7:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Dmitry Koterov" <dmitry@koterov.ru> writes:
> Thank you for a possible solution.
> But what about the database which exists and works correctly (and conforms
> all the standards from the documentation), but dump+restore sequence is
> failed for it? Does it mean that pg_dump should be improved to pass
> dump+restore sequence?

No matter what pg_dump does, it can never guarantee that a non-immutable
check constraint will still pass at restore time ... and that's
basically what you've got, if the check function is
search-path-sensitive.

                       regards, tom lane

pgsql-hackers by date:

Previous
From: Unicron
Date:
Subject: A error reported in patch "clientcert option for pg_hba"
Next
From: Chris Browne
Date:
Subject: Re: Simple postgresql.conf wizard