Skip site navigation (1) Skip section navigation (2)

Re: Fixing pg_dump

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fixing pg_dump
Date: 2004-06-28 03:20:17
Message-ID: 40DF8E71.1040302@familyhealth.com.au (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-06-28 03:21:51
Subject: Re: Fixing pg_dump
Previous:From: Tom LaneDate: 2004-06-28 03:11:23
Subject: Unifying type and function names

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group