On Sat, 23 Aug 2025 09:36:07 -0500
Nathan Bossart <nathandbossart@gmail.com> wrote:
> On Sat, Aug 23, 2025 at 05:32:30AM -0400, Corey Huinker wrote:
> > On Fri, Aug 22, 2025 at 11:20 PM Fujii Masao <masao.fujii@gmail.com> wrote:
> >> On Sat, Aug 23, 2025 at 12:00 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> >>> Hm. Maybe we should just document that the option requires SELECT
> >>> privileges on pg_statistic and pg_statistic_ext_data (which are restricted
> >>> to superusers by default). I suspect we have relatively limited
> >>> opportunities for tuning the query, and I'd like to avoid invasive changes
> >>> to v18 at this point.
> >>
> >> Yeah, adding a note about the permissions required for --missing-stats-only,
> >> leaving the query unchanged in v18, and revisiting the issue in v19 seems
> >> reasonable given the limited time before the v18 release.
> >
> > Rather than resorting to the redundant where-clause trick that we did in
> > pg_dump.
>
> Here's a patch for the documentation update.
The documentation fix looks good to me. However, it’s not very user-friendly that,
when the user lacks the required privileges, an error from the internal query is
raised. Instead, how about checking whether the user has the necessary privileges
and printing an appropriate message if any privilege is missing?
I've added the 0002 patch to address this; the 0001 is the same as the previous.
The check is performed per database, so it may be a bit slower when an enormous
number of databases are processed, but the overhead should be relatively small compared
with the other queries executed together.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
