Re: pgsql: Rework the pg_statistic_ext catalog
От | Tomas Vondra |
---|---|
Тема | Re: pgsql: Rework the pg_statistic_ext catalog |
Дата | |
Msg-id | 20190616085651.d2hxuiqlojewed5j@development обсуждение исходный текст |
Ответ на | Re: pgsql: Rework the pg_statistic_ext catalog (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: pgsql: Rework the pg_statistic_ext catalog
|
Список | pgsql-committers |
On Sun, Jun 16, 2019 at 07:18:58AM +0100, Dean Rasheed wrote: >On Sun, 16 Jun 2019, 03:05 Tom Lane, <tgl@sss.pgh.pa.us> wrote: > >> I wrote: >> > Tomas Vondra <tomas.vondra@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. > Yeah, that's pretty much why we split the catalog - to allow pg_dump to read the definitions, without exposing the stats too. I'll look into this and push a fix to unbreak the buildfarm (sorry about that). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления: