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 d7df81620811140634k7695e17ag6bb52171ad5e4844@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>)
Responses Re: Sometimes pg_dump generates dump which is not restorable
List 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@sss.pgh.pa.us> wrote:
"Dmitry Koterov" <dmitry@koterov.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: WIP: Column-level Privileges
Next
From: "Robert Haas"
Date:
Subject: Re: CREATE AGGREGATE disallows STYPE = internal