Re: Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata") - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")
Date
Msg-id 20130907180152.GF11757@momjian.us
Whole thread Raw
In response to Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Re: Privileges for INFORMATION_SCHEMA.SCHEMATA (was Re: [DOCS] Small clarification in "34.41. schemata")
List pgsql-hackers
On Thu, Jan 31, 2013 at 03:49:36PM -0500, Peter Eisentraut wrote:
> On 1/9/13 8:56 PM, Tom Lane wrote:
> > However, it seems to me that this behavior is actually wrong for our
> > purposes, as it represents a too-literal reading of the spec.  The SQL
> > standard has no concept of privileges on schemas, only ownership.
> > We do have privileges on schemas, so it seems to me that the consistent
> > thing would be for this view to show any schema that you either own or
> > have some privilege on.  That is the test should be more like
> >
> >     pg_has_role(n.nspowner, 'USAGE')
> >     OR has_schema_privilege(n.oid, 'CREATE, USAGE')
> >
> > As things stand, a non-superuser won't see "public", "pg_catalog",
> > nor even "information_schema" itself in this view, which seems a
> > tad silly.
>
> I agree it would make sense to change this.

Is this the patch you want applied?  The docs are fine?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PERFORM] encouraging index-only scans
Next
From: Bruce Momjian
Date:
Subject: Re: [RFC] overflow checks optimized away