Jeff Amiel <[EMAIL PROTECTED]> writes:
> I guess the real question is (other than related to this issue), it there
> any need to dump the catalog/informational schemas?
There isn't, but pg_dump won't dump them anyway; you have no need to
specify switches for that.
The whole business of partia
Tom Lane <[EMAIL PROTECTED]> wrote:I think that would have excluded anything
that didn't demonstrably
belong to schema public, such as procedural languages. Is it possible
that *all* your functions failed to load, and you only noted the ensuing
GRANT/REVOKE failures?
yes...ALL my functions did i
Jeff Amiel <[EMAIL PROTECTED]> writes:
> The original pg_dump used --schema="public" .
I think that would have excluded anything that didn't demonstrably
belong to schema public, such as procedural languages. Is it possible
that *all* your functions failed to load, and you only noted the ensuing
Jeff Amiel <[EMAIL PROTECTED]> writes:
> did a pg_dump --format=c for a production database (on a 8.1.2 server) and
> attempted to pg_restore on a 8.2.0 server.
> Things seemed to go fine with the exception of functions, triggers and
> trigger functions.
Seems pretty strange. Can you strip thi
The original pg_dump used --schema="public" .
Could the fact that pg_catalog or information_schema weren't included cause
these kinds of issues? (I can't imagine why)
<[EMAIL PROTECTED]> wrote: did a pg_dump --format=c for a production database
(on a 8.1.2 server) and attempted to pg_restore
did a pg_dump --format=c for a production database (on a 8.1.2 server) and
attempted to pg_restore on a 8.2.0 server.
Things seemed to go fine with the exception of functions, triggers and trigger
functions.
It was apparently doing a bunch of ACL work towards the end and spewed a slew
of error
