Re: Default Roles (was: Additional role attributes) - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Default Roles (was: Additional role attributes)
Date
Msg-id 20160405023138.GA1641028@tornado.leadboat.com
Whole thread Raw
In response to Re: Default Roles (was: Additional role attributes)  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Default Roles (was: Additional role attributes)
Re: Default Roles (was: Additional role attributes)
List pgsql-hackers
On Sun, Apr 03, 2016 at 10:27:02PM -0400, Stephen Frost wrote:
> * Fujii Masao (masao.fujii@gmail.com) wrote:
> > Currently only superusers can call pgstattuple().
> 
> I started looking into this.
> 
> If we were starting from a green field, the pg_dump dump catalog ACLs
> patch would work just fine for this case.  Simply remove the superuser
> checks and REVOKE EXECUTE from public in the script and we're done.
> 
> Unfortunately, we aren't, and that's where things get complicated.  The
> usual pg_upgrade case will, quite correctly, dump out the objects
> exactly as they exist from the 9.5-or-earlier system and restore them
> into the 9.6 system, however, the new .so will be installed and that .so
> won't have the superuser checks in it.
> 
> The only approach to addressing this which I can think of offhand would
> be to have the new .so library check the version of the extension and,
> for the 1.3 (pre-9.6) and previous versions, keep the superuser check,
> but skip it for 1.4 (9.6) and later versions.

At the C level, have a pgstattuple function and a pgstattuple_v1_4 function.
Let them differ only in that the former has a superuser check.  Binary
upgrades will use the former, and fresh CREATE EXTENSION shall use the latter.



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: oversight in parallel aggregate
Next
From: Tom Lane
Date:
Subject: Re: oversight in parallel aggregate