Re: pgsql: Rework the pg_statistic_ext catalog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>
Cc: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Rework the pg_statistic_ext catalog
Date: 2019-06-16 02:05:44
Message-ID: 20156.1560650744@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

I wrote:
> Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Dean Rasheed 2019-06-16 06:18:58 Re: pgsql: Rework the pg_statistic_ext catalog
Previous Message Tom Lane 2019-06-16 01:18:18 Re: pgsql: Rework the pg_statistic_ext catalog