From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Gary Doades <gpd(at)gpdnet(dot)co(dot)uk>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Permissions problem with sequences |
Date: | 2004-09-09 03:11:24 |
Message-ID: | 20040909031124.GA86235@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Sep 06, 2004 at 11:41:48PM -0400, Tom Lane wrote:
> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> >> Given that pg_dump does put out GRANT/REVOKE operations on the sequence,
> >> it's certainly aware that the sequence exists. I suspect this is just a
> >> fixable bug (ie, suppression of output of the sequence CREATE command is
> >> being done at the wrong place).
>
> > I'm trying to think of the solution here.
>
> One way is to allow the ArchiveEntry to be created (ie, suppress the
> discrimination against owned sequences at pg_dump.c:7306) and instead
> discriminate at the point of emitting the CREATE or DROP from the
> ArchiveEntry ... but not when emitting an ALTER OWNER from it.
I raised a question in my original post that I haven't seen discussed:
Is failing to change the sequence ownership a bug in pg_dump, or
should changing a table's ownership also change the ownership of
implicitly-created sequences? That seems the most reasonable
behavior to me: I'd expect that the cases where you wouldn't want
this to happen would be the exception, not the rule. DROP TABLE
cascades to implictly-created sequences -- why shouldn't ALTER TABLE
OWNER TO cascade as well?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-09 03:59:46 | Re: Permissions problem with sequences |
Previous Message | Michael Fuhr | 2004-09-09 02:47:43 | Build failure: TIMEZONE_GLOBAL undeclared |