Skip site navigation (1) Skip section navigation (2)

Re: WIP: Column-level Privileges

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Markus Wanner <markus(at)bluegap(dot)ch>,PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Column-level Privileges
Date: 2008-11-25 21:03:08
Message-ID: 20081125210308.GD4452@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro,

* Alvaro Herrera (alvherre(at)commandprompt(dot)com) wrote:
> I had a look at aclchk.c and didn't like your change to
> objectNamesToOids; seems rather baroque.  I changed it per the attached
> patch.

I've incorporated this change.

> Moreover I didn't very much like the way aclcheck_error_col is dealing
> with two or one % escapes.  I think you should have a separate routine
> for the column case, and prepend a dummy string to no_priv_msg.

I can do this, not really a big deal.

> Why is there a InternalGrantStmt.rel_level?  Doesn't it suffice to
> check whether col_privs is NIL?

No, a single statement can include both relation-level and column-level
permission changes.  The rel_level flag is there to indicate if there
are any relation-level changes.  Nothing else indicates that.

> Is there enough common code in ExecGrant_Relation to justify the way you
> have it?  Can the common be refactored in a better way that separates
> the two cases more clearly?

I've looked at this a couple of times and I've not been able to see a
good way to do that.  I agree that there's alot of common code and it
seems like there should be a way to factor it out, but there are a
number of differences that make it difficult.  If you see something I'm
missing, please let me know.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Rob KirkbrideDate: 2008-11-25 21:05:58
Subject: Re: Enhancement to pg_dump
Previous:From: Gregory StarkDate: 2008-11-25 20:58:45
Subject: Re: Enhancement to pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group