From: | "Dmitry Koterov" <dmitry(at)koterov(dot)ru> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Sometimes pg_dump generates dump which is not restorable |
Date: | 2008-11-15 10:04:28 |
Message-ID: | d7df81620811150204l23485fc3gc86269ee93092bf7@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Dmitry Koterov" <dmitry(at)koterov(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2008-11-15 11:58:36 | Re: So what's an "empty" array anyway? |
Previous Message | Unicron | 2008-11-15 09:47:57 | A error reported in patch "clientcert option for pg_hba" |