Re: Bug / shortcoming in has_*_privilege

On Wed, Aug 11, 2010 at 8:51 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Wed, 2010-08-11 at 06:48 -0400, Robert Haas wrote:
>> On Wed, Aug 11, 2010 at 3:57 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> > On Thu, 2010-06-10 at 23:18 -0400, Tom Lane wrote:
>> >> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> >> > On Thu, Jun 10, 2010 at 5:54 PM, Jim Nasby <jim(at)nasby(dot)net> wrote:
>> >> >> So there's no way to see if a particular privilege has been granted to public. ISTM 'public' should be accepted, since you can't use it as a role name anyway...
>> >>
>> >> > It's a bit sticky - you could make that work for
>> >> > has_table_privilege(name, oid, text) or has_table_privilege(name,
>> >> > text, text), but what would you do about the versions whose first
>> >> > argument is an oid?
>> >>
>> >> Nothing.  The only reason to use those forms is in a join against
>> >> pg_authid, and the "public" group doesn't have an entry there.
>> >
>> > ISTM this bug should be on the open items list...
>>
>> I don't think this is a bug.
>
> It clearly rates higher in importance than most of the things on the
> open items list of late...

First, I don't think that's true. WALreceiver crashing on AIX, the
backup procedure in the manual possibly being wrong, and the
documentation failing to be installed sometimes all seem like they are
clearly more serious issues than this. I am sort of wondering why no
one is working on those issues; apparently, nobody other than me minds
if it takes another three months to get 9.0 out the door. Frankly, I
think the ExplainOnePlan bit is more important, too, although I'm
starting to think we should fix that for 9.1 rather than 9.0.

Second, even if it were true, the fact that something is important
does not make it a bug fix.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company