On Sat, May 18, 2019 at 11:49:06AM -0700, Andres Freund wrote:
Hi,
On May 18, 2019 8:43:29 AM PDT, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
On Sat, 18 May 2019 at 16:13, Tom Lane <t...@sss.pgh.pa.us> wrote:
Dean Rasheed <dean.a.rash...@gmail.com> writes:
> 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.
It seems like what we need here is to have a separation between the
*definition* of a stats object (which is what pg_dump needs access
to) and the current actual *data* in it. I'd have expected that
keeping those in separate catalogs would be the thing to do, though
perhaps it's too late for that.
Yeah, with the benefit of hindsight, that would have made sense, but
that seems like a pretty big change to be attempting at this stage.
Otoh, having a suboptimal catalog representation that we'll likely have
to change in one of the next releases also isn't great. Seems likely
that we'll need post beta1 catversion bumps anyway?
But that's not an issue intruduced by PG12, it works like that even for
the extended statistics introduced in PG10.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
