On Sun, 16 Jun 2019, 03:05 Tom Lane, <t...@sss.pgh.pa.us> wrote: > I wrote: > > Tomas Vondra <tomas.von...@postgresql.org> writes: > >> Rework the pg_statistic_ext catalog > > > So ... not one of the buildfarm members that are running TAP tests > > likes this. ... > > I think probably what's happening is that pg_dump is still trying to dump > > directly from the catalog, when what it needs to do now is dump from the > > view, in case it's not running as superuser. > > I experimented with extracting the required data from the view, and > there are at least two show-stopper problems: > > * The view doesn't expose pg_statistic_ext.oid, which pg_dump has to have > for dependency tracking purposes. I think we could just add it though. > Now that OIDs are ordinary columns it won't even look very odd. > > * Rather than just not exposing the critical data for stats you don't > have privilege to read, the view doesn't expose anything at all. > I do not think that's acceptable; it creates a significant hazard of > data loss during pg_dump, for no very good reason. What we should > be doing, IMO, is still showing all the rows but filling the data-value > columns with nulls in rows where the caller can't access the underlying > data. > >
Hang on. Isn't the real problem that we should be revoking public access from pg_statistic_ext_data, not pg_statistic_ext? Normal users should still be able to see the stats definitions in the catalog table, but not the stats data, so I think pg_dump wouldn't need changing. Regards, Dean >
