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>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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=f7c62462402972b13d10e43f104ca0c0fecb6d08I 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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=f7c62462402972b13d10e43f104ca0c0fecb6d08I 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>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers