Re: ExecutorCheckPerms() hook

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ExecutorCheckPerms() hook
Date: 2010-05-20 17:33:55
Message-ID: 6068.1274376835@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, May 20, 2010 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hm, I think you need to ignore RT entries that have no requiredPerms
>> bits set. (Not that it matters too much, unless you were proposing to
>> actually commit this contrib module.)

> Well, that's an easy change - just out of curiosity, how do we end up
> with RT entries with no requiredPerm bits set?

Inheritance child tables look like that now, per the discussion
awhile back that a SELECT on the parent shouldn't require any
particular permission on the individual child tables. IIRC there
are some other cases involving views too, but those are probably
just optimizations (ie not do duplicate permissions checks) rather
than something that would result in a user-visible behavioral issue.

> As for committing it, I would definitely like to commit the actual
> hook. If we want the hook without the contrib module that's OK with
> me, although I generally feel it's useful to have examples of how
> hooks can be used, which is why I took the time to produce a working
> example.

+1 on committing the hook. As for the contrib module, it doesn't strike
me that there's much of a use-case for it as is. I think it's enough
that it's available in the -hackers archives.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2010-05-20 17:35:22 Re: Snapshot Materialized Views - GSoC
Previous Message Robert Haas 2010-05-20 16:37:07 Re: ExecutorCheckPerms() hook