Re: pg_dump/restore and functions/triggers/trigger functions - Mailing list pgsql-general

From Jeff Amiel
Subject Re: pg_dump/restore and functions/triggers/trigger functions
Date
Msg-id 730548.72926.qm@web60813.mail.yahoo.com
Whole thread Raw
In response to Re: pg_dump/restore and functions/triggers/trigger functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump/restore and functions/triggers/trigger functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane <tgl@sss.pgh.pa.us> 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 indeed fail to load.
Weirdness is that I only saw errors on the GRANT/REVOKE failures.
Huh.

I created a simple test case with a single function...got the same results.
I removed the --schema='public' and it worked fine.
I compared the TOCs on the 2 different files and sure enough, there is an entry on the one that DIDN'T only use public that had the plpgsql entry.

248; 2612 90212 PROCEDURAL LANGUAGE - plpgsql

Huh.  I guess if I added plpgsql to template1 before I created the empty shell db to restore into, I would never have seen this issue.
Ok....
I guess the real question is (other than related to this issue), it there any need to dump the catalog/informational schemas?


Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.

pgsql-general by date:

Previous
From: MargaretGillon@chromalloy.com
Date:
Subject: Limit for number of Joins in a View? Version 8.1.4 on Redhat 9
Next
From: Jorge Godoy
Date:
Subject: Re: leaving this group