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-14 14:34:02 |
Message-ID: | d7df81620811140634k7695e17ag6bb52171ad5e4844@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Besides that, for pg_dump has corresponding behaviour CONSTRAINT = FOREIGN
KEY.
For CONSTRAINT = CHECK - it hasn't.
On Thu, Nov 13, 2008 at 9:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Dmitry Koterov" <dmitry(at)koterov(dot)ru> writes:
> > 3. The function a() calls any OTHER function b() from OTHER namespace (or
> > uses operators from other namespaces), but does not specify the schema
> name,
> > because it is in database search_path:
>
> > CREATE FUNCTION a(i integer) RETURNS boolean AS $$
> > BEGIN
> > PERFORM b(); -- b() is is from "nsp" schema
> > RETURN true;
> > END;$$ LANGUAGE plpgsql IMMUTABLE;
>
> I think your function is broken. You might want to fix it by attaching
> a local search_path setting to it.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2008-11-14 14:40:09 | Re: CREATE AGGREGATE disallows STYPE = internal |
Previous Message | Alvaro Herrera | 2008-11-14 13:50:33 | Re: WIP: Column-level Privileges |