Re: pgsql: Rework the pg_statistic_ext catalog
От | Tom Lane |
---|---|
Тема | Re: pgsql: Rework the pg_statistic_ext catalog |
Дата | |
Msg-id | 20156.1560650744@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Rework the pg_statistic_ext catalog (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Rework the pg_statistic_ext catalog
|
Список | pgsql-committers |
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. regards, tom lane
В списке pgsql-committers по дате отправления: