Greg Stark <gsstark@mit.edu> writes:
> I can't think of a good approach for migration of old pg_dumps though, so
> perhaps this is more trouble than it's worth.
That would probably be the major objection to any redefinition of the
meanings of the individual sequence permissions. We could possibly
invent a couple of brand new permission bits though, and stipulate that
"UPDATE" incorporates them both.
> Implicit sequences on the other hand can be migrated easily by ignoring all
> explicit grants and just looking at the grants on the table.
It's not really that easy. Before we hack up the permissions system like
this I'd want to see a complete solution, which this is not, because it
doesn't work in the context of rules. Consider
CREATE TABLE t (id SERIAL ...);
CREATE VIEW v AS SELECT * FROM t;
CREATE RULE r AS ON INSERT TO v DO INSTEAD INSERT INTO t ...
GRANT INSERT ON v TO joeuser;
joeuser will be able to invoke the insertion rule, but nextval() will
still fail because it doesn't know about the rule context --- it'll
see joeuser as the current user, not the owner of the rule.
Eventually I'd like to replace the nextval('foo') notation with a parsed
construct foo.nextval, which is (a) Oracle compatible, (b) able to
withstand renamings of the foo sequence, and (c) amenable to having the
permissions check done during rangetable scanning, which would fix the
rule problem. There is some discussion of this in the pghackers archives.
regards, tom lane