On Sat, 18 May 2019 at 10:11, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Fri, 17 May 2019 at 21:29, Andres Freund <andres@anarazel.de> wrote:
> >
> > On 2019-05-16 14:28:03 +0100, Dean Rasheed wrote:
> > > 5). Some columns from pg_statistic_ext have to be made visible for
> > > psql \d to work. Basically, it needs to be able to query for the
> > > existence of extended statistics, but it doesn't need to see the
> > > actual statistical data. Of course, we could change psql to use the
> > > view, but this way gives us better backwards compatibility with older
> > > clients.
> > >
> > > This is still going to break compatibility of any user code looking at
> > > stxndistinct or stxdependencies from pg_statistic_ext, but at least it
> > > doesn't break old versions of psql.
> >
> > Hm, it's not normally a goal to keep old psql working against new
> > postgres versions. And there's plenty other issues preventing a v11 psql
> > to work against 12. I'd not let this guide any design decisions.
> >
>
> Ah good point. In fact running "\d some_table" from v11's psql against
> a v12 database immediately falls over because of the removal of
> relhasoids from pg_class, so this isn't a valid reason for retaining
> access to any columns from pg_statistic_ext.
>
On the other hand, pg_dump relies on pg_statistic_ext to work out
which extended statistics objects to dump. If we were to change that
to use pg_stats_ext, then a user dumping a table with RLS using the
--enable-row-security flag wouldn't get any extended statistics
objects, which would be a somewhat surprising result.
That could be fixed by changing the view to return rows for every
extended statistics object, nulling out values in columns that the
user doesn't have permission to see, in a similar way to Tomas'
original patch. It would have to be modified to do the RLS check in
the same place as the privilege checks, rather than in the top-level
WHERE clause, and we'd probably also have to expose OIDs in addition
to names, because that's what clients like psql and pg_dump want. To
me, that feels quite messy though, so I think I'd still vote for
leaving the first few columns of pg_statistic_ext accessible to
public, and not have to change the clients to work differently from
v12 onwards.
Regards,
Dean
