Thread: [HACKERS] Backport of pg_statistics typos fix
Hi, I found typos "pg_statistics" in REL9_6_STABLE, but that has been fixed in the master branch. Fix typo: pg_statistics -> pg_statistic https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5a366b4ff4ceceb9793fcc13c3f097ee0d32c56d;hp=f7c62462402972b13d10e43f104ca0c0fecb6d08 I think it would be better to backport this to other branches. Regards, -- Yugo Nagata <nagata@sraoss.co.jp>
On Tue, Feb 7, 2017 at 4:22 AM, Yugo Nagata <nagata@sraoss.co.jp> wrote: > I found typos "pg_statistics" in REL9_6_STABLE, but that has been > fixed in the master branch. > > Fix typo: pg_statistics -> pg_statistic > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5a366b4ff4ceceb9793fcc13c3f097ee0d32c56d;hp=f7c62462402972b13d10e43f104ca0c0fecb6d08 > > I think it would be better to backport this to other branches. We usually leave such decisions to the discretion of the committer, because back-porting such changes takes time and sometimes it just isn't that important. Nobody's likely to be confused by a few instances of writing pg_statistics rather than pg_statistic. Personally, I favor not back-porting such things in most cases, because I think patches that get back-ported should be strictly limited to bug fixes, and typos in code comments aren't bug fixes. But not everyone has the same opinion on this. What's your reason for wanting it back-ported? BTW, looking at that commit, this change looks to have adjusted this from being wrong to still being wrong: -<listitem><para>Allow pg_statistics to be reset by calling pg_stat_reset() (Christopher)</para></listitem> +<listitem><para>Allow pg_statistic to be reset by calling pg_stat_reset() (Christopher)</para></listitem> It's true that pg_stat_reset() doesn't reset the nonexistent pg_statistics table. But it doesn't reset pg_statistic either. IIUC, it resets the data gathered by the statistics collector, which is something else altogether. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 8 Feb 2017 14:54:17 -0500 Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Feb 7, 2017 at 4:22 AM, Yugo Nagata <nagata@sraoss.co.jp> wrote: > > I found typos "pg_statistics" in REL9_6_STABLE, but that has been > > fixed in the master branch. > > > > Fix typo: pg_statistics -> pg_statistic > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5a366b4ff4ceceb9793fcc13c3f097ee0d32c56d;hp=f7c62462402972b13d10e43f104ca0c0fecb6d08 > > > > I think it would be better to backport this to other branches. > > We usually leave such decisions to the discretion of the committer, > because back-porting such changes takes time and sometimes it just > isn't that important. Nobody's likely to be confused by a few > instances of writing pg_statistics rather than pg_statistic. > Personally, I favor not back-porting such things in most cases, > because I think patches that get back-ported should be strictly > limited to bug fixes, and typos in code comments aren't bug fixes. > But not everyone has the same opinion on this. What's your reason for > wanting it back-ported? I agree typos in code comments aren't bug fixes and not need to get back-ported. However, there are typos also in the document. The <function>scalarltsel</function> function retrieves the histogram for <structfield>unique1</structfield> from - <structname>pg_statistics</structname>. For manual queries it is more + <structname>pg_statistic</structname>. For manual queries it is more convenient to look in the simpler <structname>pg_stats</structname> view: I think this might be a document bug, but if nobody cares of it, I also don't mind. Thanks, > > BTW, looking at that commit, this change looks to have adjusted this > from being wrong to still being wrong: > > -<listitem><para>Allow pg_statistics to be reset by calling > pg_stat_reset() (Christopher)</para></listitem> > +<listitem><para>Allow pg_statistic to be reset by calling > pg_stat_reset() (Christopher)</para></listitem> > > It's true that pg_stat_reset() doesn't reset the nonexistent > pg_statistics table. But it doesn't reset pg_statistic either. IIUC, > it resets the data gathered by the statistics collector, which is > something else altogether. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Yugo Nagata <nagata@sraoss.co.jp>
On 2/8/17 14:54, Robert Haas wrote: > BTW, looking at that commit, this change looks to have adjusted this > from being wrong to still being wrong: > > -<listitem><para>Allow pg_statistics to be reset by calling > pg_stat_reset() (Christopher)</para></listitem> > +<listitem><para>Allow pg_statistic to be reset by calling > pg_stat_reset() (Christopher)</para></listitem> > > It's true that pg_stat_reset() doesn't reset the nonexistent > pg_statistics table. But it doesn't reset pg_statistic either. IIUC, > it resets the data gathered by the statistics collector, which is > something else altogether. Fixed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services