On Fri, Nov 1, 2013 at 3:52 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:
> I've been looking some more into write-side checks in row-security and
> have a suggestion.
>
> Even though write-side checks are actually fairly separate to read
> checks, and can be done as another step, I'd like to think about them
> before the catalog format and syntax are settled. I think we need fields
> for write operations in pg_rowsecurity and the syntax to set them so
> that the catalog information can be used by triggers to enforce write
> checks. Even if, for the first cut, they're not supported by built-in
> auto-created triggers.
>
> Here's my proposal, let me know what you think:
>
> SET ROW SECURITY FOR { ALL COMMANDS | {[SELECT,INSERT,UPDATE,DELETE}+}
>
> in other words, you specify either:
>
> SET ROW SECURITY FOR ALL COMMANDSI continue to think that this syntax is misguided. For SELECT and DELETE there is only read-side security, and for INSERT there is only write-side security, so that's OK as far as it goes, but for UPDATE both read-side security and write-side security are possible, and there ought to be a way to get one without the other. This syntax won't support that cleanly. I wonder whether it's worth thinking about the relationship between the write-side security contemplated for this feature iand the WITH CHECK OPTION syntax that we have for auto-updateable views, which serves more or less the same purpose. I'm not sure that syntax is any great shakes, but it's existing precedent of some form and could perhaps at least be looked at as a source of inspiration. I would generally expect that most people would want either "read side security for all commands" or "read and write side security for all commands". I think whatever syntax we come up with this feature ought to make each of those things straightforward to get. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
