Re: Proposal: GRANT cascade to implicit sequences - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Proposal: GRANT cascade to implicit sequences
Date
Msg-id 200411110444.iAB4i1o10268@candle.pha.pa.us
Whole thread Raw
In response to Re: Proposal: GRANT cascade to implicit sequences  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I looked over this thread and can't see any TODO item.  Having GRANT
just propogate from the table to a SERIAL sequence doesn't work because
an INSERT into a table is an UPDATE of the sequence.

Is there a TODO here?

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-general by date:

Previous
From: Kris Jurka
Date:
Subject: Re: updateString error in PostgreSQL7.4 with JDBC
Next
From: Kevin Barnard
Date:
Subject: Re: Important Info on comp.databases.postgresql.general