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

From Stephen Frost
Subject Re: Default Roles (was: Additional role attributes)
Date
Msg-id 20160406015301.GE10850@tamriel.snowman.net
Whole thread Raw
In response to Re: Default Roles (was: Additional role attributes)  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah,

* Noah Misch (noah@leadboat.com) wrote:
> 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.

Excellent suggestion and many thanks for that.

I'll draft up a patch for that.

Thanks again!

Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Next
From: Craig Ringer
Date:
Subject: Re: Timeline following for logical slots