From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, Gary Doades <gpd(at)gpdnet(dot)co(dot)uk>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Permissions problem with sequences |
Date: | 2004-09-07 03:04:56 |
Message-ID: | 413D2558.3080201@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
>>However, of course the best thing is to just fix it, which I guess I'll
>>have a crack at...
>
>
> 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).
Hrm. This seems to be a bug introduced when I moved the OWNER TO
commands to be dumped after each object's definition is dumped, instead
of just before their ACL is dumped.
The problem is that although the SERIAL sequence has an ACL, it has no
object, so it never has an OWNER TO command dumped.
I'm trying to think of the solution here. I guess we can move the OWNER
TO commands to be dumped in the ACL phase, or we can make a special
exception for serial sequences.
Also, are there any other objects that are going to have this problem?
Off the top of my head it's only serial sequences.
What's the best solution? I guess we have to put them back on the acl_pass?
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-07 03:41:48 | Re: Permissions problem with sequences |
Previous Message | Tom Lane | 2004-09-06 23:57:42 | Re: [PATCHES] [pgsql-hackers-win32] Win32 deadlock detection not working for Postgres8beta1 |