I don't buy it. There's a tradeoff here between certainty of doing what you want and having a script that is easy to edit. DROP is a dangerous weapon and we should be circumspect about applying it, but ALTER OWNER etc are much less so.
Also, the point about qualifying the DROP is that you do not know whether the object is there initially, and so you could be dropping the wrong thing even in non-error cases. The scenario where the CREATE fails is much less probable.
OK, does it matter then if I leave the ALTER OWNER statement qualified? It would be a pain in the butt to parse off the existing DROP command's namespace qualification.
I've run into an ACLs problem now. This is the situation:
ALTER TABLE public.forums_threads OWNER TO usadmin;
-- -- Name: forums_threads; Type: ACL; Schema: public; Owner: usadmin --
REVOKE ALL ON TABLE forums_threads FROM PUBLIC; REVOKE ALL ON TABLE forums_threads FROM usadmin; SET SESSION AUTHORIZATION brett; GRANT ALL ON TABLE forums_threads TO brett WITH GRANT OPTION; RESET SESSION AUTHORIZATION;
It fails trying to grant brett the GRANT OPTION as the user brett. I haven't yet looked into the logic behind dumping these acls in common.c, but it seems that maybe it's a hangover from historical alter owner commands on that relation? ie. The acl is still there from when brett used to own that table?
Do you still plan to fix that? I'll see if there's anything I can do in pg_dump to detect the condition and fix it if you like.
Chris
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
