Horton

Thread

Commits

  1. Fix typos and grammar in code and test comments

  2. Standardize references to Zstandard as <productname>

  3. CREATE PUBLICATION ref: Minor tweaks to row filters

  4. Add missing spaces after single-line comments

  5. Docs: fix some spelling mistakes and also do some wordsmithing

  6. Remove extraneous blank lines before block-closing braces

  7. Docs: wording improvement for compute_query_id = regress

  8. Docs: tidy up various usages of the productname tag

  9. Docs: adjust wording about basebackup_to_shell's required_role GUC

  10. Docs: adjust pg_upgrade syntax to mark -B as optional

  11. Docs: avoid confusing use of the word "synchronized"

  12. Fix grammatical errors and typos in logical replication docs.

  13. Docs: Mention that relpersistence is for sequences now too

  14. Fix various typos and spelling mistakes in code comments

  15. Docs: Fix various mistakes and typos

  1. typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-11T02:03:36Z

    In docs and comments.  Mostly for v15.
Maybe Fabien will want to comment on the pgbench one.

  2. Re: typos

    David Rowley <dgrowleyml@gmail.com> — 2022-04-11T04:39:30Z

    ( Added Joe and Robert for 0011 )

On Mon, 11 Apr 2022 at 14:03, Justin Pryzby <pryzby@telsasoft.com> wrote:
> In docs and comments.  Mostly for v15.

0001:

Should this not use <productname>PostgreSQL</productname>? (new to master)

0002:

The patch looks good. (new to v12)

0003:

The patch looks good. (new to master)

0004:

The patch looks good. (new to master)

0005:

I'm not entirely certain this is an improvement.  Your commit message
I'd say is not true going by git grep "compression algorithm". There
are 3 matches in the docs and take [1], for example. I'd say in that
one it's better to use "algorithm".  In that case, "method" could be
talking about client or server.

That makes me wonder if the change you're proposing is an improvement or not.

0006:

The patch looks good. (new to master)

0007:

-        When the <option>--max-tries</option> option is used, the
transaction with
-        serialization or deadlock error cannot be retried if the total time of
+        When the <option>--max-tries</option> option is used, a
transaction with
+        serialization or deadlock error will not be retried if the
total time of

Shouldn't this be slightly clearer and say "a transaction which fails
due to a serialization anomaly or a deadlock"?

-               database server / the syntax error in the meta command / thread
+               database server / syntax error in the meta command / thread

Should we not separate these items out with commas?

-   the client is aborted. Otherwise, if an SQL fails with serialization or
+   the client is aborted. Otherwise, if an SQL command fails with
serialization or
    deadlock errors, the client is not aborted. In such cases, the current

I'd say "if an SQL command fails due to a serialization anomaly or due
to deadlocking".

(new to master)

0008:

The patch looks good. (new to master)

0009:

The patch looks good. (new to master)

0010:

I don't understand this change.

0011:

I can't quite parse the original. I might not have enough context
here.  Robert, Joe? (new to master)

0012:

This seems to contain some documentation fixes too. The patch claims
it's just for comments.

- * pages that are outwith that range.
+ * pages that are outside that range.

I personally don't see the issue here, but I'm Scottish. I think the
best transaction is just "outside of" rather than replacing with just
"outside".

All the other changes look fine.

0013:

I think we should fix all these, regardless of how old the mistake is.

0014:

- * shouldn't PANIC just because we can't guarantee the the backup has been
+ * shouldn't PANIC just because we can't guarantee the backup has been

"that the"

0015:

Patch looks fine.

0016:
0017:

I'm not really sure if we should fix these or not.  From having a
quick look at some of them it seems we'd be adding churn to some
pretty old code. Happy to hear what others think.

0018:

The patch looks good.

0019:

-1. pgindent will fix these.

I will start pushing the less controversial of these, after a bit of squashing.

David

[1] https://www.postgresql.org/docs/devel/app-pgbasebackup.html

  3. Re: typos

    David Rowley <dgrowleyml@gmail.com> — 2022-04-11T08:55:43Z

    On Mon, 11 Apr 2022 at 16:39, David Rowley <dgrowleyml@gmail.com> wrote:
> I will start pushing the less controversial of these, after a bit of squashing.

I just committed 3 separate commits for the following:

Committed: 0001 + 0003 + 0004 + 0006 + 0007 (modified) + 0008 + 0009 +
0012 (doc parts)
Committed: 0012 (remainder) + 0013 + 0014 + 0018
Committed: 0015

I skipped:
0002 (skipped as we should backpatch)
0005 (unsure if the proposed patch is better)
0010 (I can't follow this change)
0011 (Could do with input from Robert and Joe)

and also skipped:
0016 (unsure if we should change these of pgindent is not touching it)
0017 (unsure if we should change these of pgindent is not touching it)
0019 (pgindent will get these when the time comes)

I'll wait for feedback on the ones I didn't use.

Are you able to rebase the remainder? Probably with the exception of 0019.

Thanks for finding all these!

David

  4. Re: typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-11T10:10:05Z

    On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> I'm not entirely certain this is an improvement.  Your commit message
> I'd say is not true going by git grep "compression algorithm". There
> are 3 matches in the docs and take [1], for example. I'd say in that
> one it's better to use "algorithm".  In that case, "method" could be
> talking about client or server.

I am not wedded to this change; but, for context, I wrote this patch before
basebackup supported multiple compression ...  "things".  I didn't touch
basebackup here, since Robert defended that choice of words in another thread
(starting at 20220320194050.GX28503@telsasoft.com).

This change is for pg_column_compression(), and the only other use of
"compression algorithm" in the docs is in pgcrypto (which is in contrib).  That
the docs consistently use "method" suggests continuing to use that rather than
something else.  It could be described in some central place (like if we
support common syntax between interfaces which expose compression).

> 0010:
> I don't understand this change.

The commit message mentions 959f6d6a1, which makes newbindir optional.  But the
documentation wasn't updated, and seems to indicate that it's still required.
https://www.postgresql.org/docs/devel/pgupgrade.html

> 0011:
> I can't quite parse the original. I might not have enough context
> here.  Robert, Joe? (new to master)

See the link in the commit message where someone else reported the same
problem.

> 0019:
> -1. pgindent will fix these.

But two of those are from 2016.

Thanks for amending and pushing those.  There's some more less obvious ones
attached.

Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
SUBSCRIPTION ... SKIP).

  5. Re: typos

    Masahiko Sawada <sawada.mshk@gmail.com> — 2022-04-11T10:25:14Z

    On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Mon, Apr 11, 2022 at 04:39:30PM +1200, David Rowley wrote:
> > I'm not entirely certain this is an improvement.  Your commit message
> > I'd say is not true going by git grep "compression algorithm". There
> > are 3 matches in the docs and take [1], for example. I'd say in that
> > one it's better to use "algorithm".  In that case, "method" could be
> > talking about client or server.
>
> I am not wedded to this change; but, for context, I wrote this patch before
> basebackup supported multiple compression ...  "things".  I didn't touch
> basebackup here, since Robert defended that choice of words in another thread
> (starting at 20220320194050.GX28503@telsasoft.com).
>
> This change is for pg_column_compression(), and the only other use of
> "compression algorithm" in the docs is in pgcrypto (which is in contrib).  That
> the docs consistently use "method" suggests continuing to use that rather than
> something else.  It could be described in some central place (like if we
> support common syntax between interfaces which expose compression).
>
> > 0010:
> > I don't understand this change.
>
> The commit message mentions 959f6d6a1, which makes newbindir optional.  But the
> documentation wasn't updated, and seems to indicate that it's still required.
> https://www.postgresql.org/docs/devel/pgupgrade.html
>
> > 0011:
> > I can't quite parse the original. I might not have enough context
> > here.  Robert, Joe? (new to master)
>
> See the link in the commit message where someone else reported the same
> problem.
>
> > 0019:
> > -1. pgindent will fix these.
>
> But two of those are from 2016.
>
> Thanks for amending and pushing those.  There's some more less obvious ones
> attached.
>
> Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> SUBSCRIPTION ... SKIP).

Thank you for the patch! I've looked at 0012 patch. Regarding the
following part:

    <function>pg_replication_origin_advance()</function></link> function
-   transaction.  Before using this function, the subscription needs
to be disabled
+   XXX? transaction.  Before using this function, the subscription
needs to be disabled
    temporarily either by <command>ALTER SUBSCRIPTION ...
DISABLE</command> or, the

we can remove "transaction", it seems a typo. The rest looks good to me.

Regards,

-- 
Masahiko Sawada
EDB:  https://www.enterprisedb.com/

  6. Re: typos

    Amit Kapila <amit.kapila16@gmail.com> — 2022-04-11T10:45:23Z

    On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > SUBSCRIPTION ... SKIP).
>
> Thank you for the patch! I've looked at 0012 patch. Regarding the
> following part:
>
>     <function>pg_replication_origin_advance()</function></link> function
> -   transaction.  Before using this function, the subscription needs
> to be disabled
> +   XXX? transaction.  Before using this function, the subscription
> needs to be disabled
>     temporarily either by <command>ALTER SUBSCRIPTION ...
> DISABLE</command> or, the
>
> we can remove "transaction", it seems a typo.
>

Right.

> The rest looks good to me.
>

+1. I'll take care of pushing this one tomorrow unless we have more
comments on this part.

-- 
With Regards,
Amit Kapila.

  7. Re: typos

    Robert Haas <robertmhaas@gmail.com> — 2022-04-11T17:59:08Z

    On Mon, Apr 11, 2022 at 4:56 AM David Rowley <dgrowleyml@gmail.com> wrote:
> 0011 (Could do with input from Robert and Joe)

Seems like a reasonable change to me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

  8. Re: typos

    Amit Kapila <amit.kapila16@gmail.com> — 2022-04-12T11:26:06Z

    On Mon, Apr 11, 2022 at 4:15 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Apr 11, 2022 at 3:55 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Mon, Apr 11, 2022 at 7:10 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > >
> > > Amit or Masahiko may want to comment on 0012 (doc review: Add ALTER
> > > SUBSCRIPTION ... SKIP).
> >
>
> +1. I'll take care of pushing this one tomorrow unless we have more
> comments on this part.
>

I have pushed this one.

-- 
With Regards,
Amit Kapila.

  9. Re: typos

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-04-13T17:29:34Z

    On 2022-Apr-11, David Rowley wrote:

> and also skipped:
> 0016 (unsure if we should change these of pgindent is not touching it)
> 0017 (unsure if we should change these of pgindent is not touching it)

I verified that pgindent will indeed not touch these changes by running
before and after.  (I accepted one comment placement from that run that
touched a neighboring line.)

I think pgindent is right not to modify vertical space very much, since
in many cases it amounts to a subjective decision.  The patch seemed a
(small) improvement, and it seems hard to make too much of a fuss about
such things.  Pushed them as a single commit.

I hadn't noticed that Justin had posted a refreshed patch series, so I
don't know if the new ones match what I pushed.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
 PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)

  10. Re: typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-13T17:40:56Z

    On Wed, Apr 13, 2022 at 07:29:34PM +0200, Alvaro Herrera wrote:
> On 2022-Apr-11, David Rowley wrote:
> 
> > and also skipped:
> > 0016 (unsure if we should change these of pgindent is not touching it)
> > 0017 (unsure if we should change these of pgindent is not touching it)
> 
> I verified that pgindent will indeed not touch these changes by running
> before and after.  (I accepted one comment placement from that run that
> touched a neighboring line.)
> 
> I think pgindent is right not to modify vertical space very much, since
> in many cases it amounts to a subjective decision.  The patch seemed a
> (small) improvement, and it seems hard to make too much of a fuss about
> such things.  Pushed them as a single commit.
> 
> I hadn't noticed that Justin had posted a refreshed patch series, so I
> don't know if the new ones match what I pushed.

There were no changes - I had resent the patches that removed blank lines so it
was apparent that they were "outstanding" / under discussion.

There's (only) a few remaining.

  11. Re: typos

    David Rowley <dgrowleyml@gmail.com> — 2022-04-13T20:56:22Z

    On Mon, 11 Apr 2022 at 22:10, Justin Pryzby <pryzby@telsasoft.com> wrote:
> Thanks for amending and pushing those.  There's some more less obvious ones
> attached.

Here are my notes from yesterday that I made when reviewing and
pushing many of the 2nd batch of patches.

0001: Pushed and back patched to v12

0002: Didn't push. Compression method/algorithm.

0003: Pushed and backpatched to v13

0004: Pushed (reviewed by Robert)

0005: Alvaro Pushed
0006: Alvaro Pushed

0007: Not pushed. No space after comment and closing */  pgindent
fixed one of these but not the other 2.  I've not looked into why
pgindent does 1 and not the other 2.

0008: Pushed

I've left out the following change as it does not seem to be bringing
any sort of consistency to the docs overall. It only brings
consistency to a single source file in the docs.

-      You need <productname>zstd</productname>, if you want to support
+      You need <productname>ZSTD</productname>, if you want to support

See: git grep -i ">zstd<"

0009:

This contains a few fixes that look correct. Not sure if the following
has any use as a change:

-    See the description of the respective commands and programs for the
-    respective details.  Note that you can mix locale providers on different
+    See the description of the respective commands and programs for
+    details.  Note that you can mix locale providers at different

0010: Pushed

0011: Not pushed. Not sure if this is worth the change.

0012: Amit Pushed

0013: Not pushed. Adds a missing comma.

David

  12. Re: typos

    David Rowley <dgrowleyml@gmail.com> — 2022-04-13T21:39:42Z

    (For the future, just to make discussions easier, it would be good if
you could have git format-patch -v N to give a unique version number
to these patches)

On Thu, 14 Apr 2022 at 05:40, Justin Pryzby <pryzby@telsasoft.com> wrote:
> There's (only) a few remaining.

I've pushed 0001 and 0002 of the 3rd batch of patches. I left 0003 as
I just didn't feel it was a meaningful enough improvement.

From docs/, if I do:

$ git grep ", which is the default" | wc -l
9

$ git grep ", the default" | wc -l
64

You're proposing to make the score 10, 63.  I'm not sure if that's a
good direction to go in.

David

  13. Re: typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-14T00:33:01Z

    On Thu, Apr 14, 2022 at 09:39:42AM +1200, David Rowley wrote:
> On Thu, 14 Apr 2022 at 05:40, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > There's (only) a few remaining.
> 
> I've pushed 0001 and 0002 of the 3rd batch of patches. I left 0003 as

Thanks

> I just didn't feel it was a meaningful enough improvement.
> 
> From docs/, if I do:
> 
> $ git grep ", which is the default" | wc -l
> 9
> 
> $ git grep ", the default" | wc -l
> 64
> 
> You're proposing to make the score 10, 63.  I'm not sure if that's a
> good direction to go in.

Well, I'm proposing to change the only instance of this:

$ git grep -F ", the default)"
doc/src/sgml/ref/create_publication.sgml:   partition's row filter (if the parameter is false, the default) or the root

Maybe what's needed is more like this.

   If the publication contains a partitioned table, and the publication parameter
   <literal>publish_via_partition_root</literal> is false (the default), then the
   row filter is taken from the partition; otherwise, the row filter is taken
   from the root partitioned table.

I'll plan to keep this around and may come back to it later.

On Thu, Apr 14, 2022 at 08:56:22AM +1200, David Rowley wrote:
> I've left out the following change as it does not seem to be bringing
> any sort of consistency to the docs overall. It only brings
> consistency to a single source file in the docs.
> 
> -      You need <productname>zstd</productname>, if you want to support
> +      You need <productname>ZSTD</productname>, if you want to support
> 
> See: git grep -i ">zstd<"

It may not be worth changing just this one line, but the reason I included it
here is for consistency:

$ git grep 'zstd.*product' doc
doc/src/sgml/config.sgml:        <literal>zstd</literal> (if <productname>PostgreSQL</productname>
$ git grep 'ZSTD.*product' doc
doc/src/sgml/install-windows.sgml:     <term><productname>ZSTD</productname></term>
doc/src/sgml/install-windows.sgml:      Required for supporting <productname>ZSTD</productname> compression
doc/src/sgml/installation.sgml:      You need <productname>ZSTD</productname>, if you want to support
doc/src/sgml/installation.sgml:         Build with <productname>ZSTD</productname> compression support.

If we were to change it, maybe they should all say "Zstandard (zstd)".  ZSTD
looks like an acronym, which I think it is not, and Zstandard indicates how to
pronounce it.

  14. Re: typos

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-04-19T11:05:23Z

    CCing Amit K, because I propose a few relatively minor changes to
logical rep docs.

On 2022-Apr-13, Justin Pryzby wrote:

> $ git grep -F ", the default)"
> doc/src/sgml/ref/create_publication.sgml:   partition's row filter (if the parameter is false, the default) or the root
> 
> Maybe what's needed is more like this.
> 
>    If the publication contains a partitioned table, and the publication parameter
>    <literal>publish_via_partition_root</literal> is false (the default), then the
>    row filter is taken from the partition; otherwise, the row filter is taken
>    from the root partitioned table.

Yeah, more invasive rewording seems called for.  I propose this:

   For publications containing partitioned tables, the row filter for each
   partition is taken from the published partitioned table if the
   publication parameter <literal>publish_via_partition_root</literal> is true,
   or from the partition itself if it is false (the default).

I think we should also mention that this parameter affects row filters,
in the <varlistentry> for the WITH clause.  Currently it has

        <term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          This parameter determines whether changes in a partitioned table (or
          on its partitions) contained in the publication will be published
          using the identity and schema of the partitioned table rather than
          that of the individual partitions that are actually changed; the
          latter is the default.  Enabling this allows the changes to be
          replicated into a non-partitioned table or a partitioned table
          consisting of a different set of partitions.
         </para>

I propose to add 

        <term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          This parameter determines whether changes in a partitioned table (or
          on its partitions) contained in the publication will be published
          using the identity and schema of the partitioned table rather than
          that of the individual partitions that are actually changed; the
          latter is the default.  Enabling this allows the changes to be
          replicated into a non-partitioned table or a partitioned table
          consisting of a different set of partitions.
         </para>

        <para>
         This parameter also affects how row filters are chosen for partitions;
         see below for details.
        </para>

More generally, I think we need to connect the WHERE keyword with "row
filters" more explicitly.  Right now, the parameter reference says

      If the optional <literal>WHERE</literal> clause is specified, rows for
      which the <replaceable class="parameter">expression</replaceable>
      evaluates to false or null will not be published. Note that parentheses
      are required around the expression. It has no effect on
      <literal>TRUNCATE</literal> commands.

I propose to make it "If the optional WHERE clause is specified, it
defines a <firstterm>row filter</firstterm> expression.  Rows for which
the row filter expression evaluates to false ..."


> $ git grep 'zstd.*product' doc
> doc/src/sgml/config.sgml:        <literal>zstd</literal> (if <productname>PostgreSQL</productname>
> $ git grep 'ZSTD.*product' doc
> doc/src/sgml/install-windows.sgml:     <term><productname>ZSTD</productname></term>
> doc/src/sgml/install-windows.sgml:      Required for supporting <productname>ZSTD</productname> compression
> doc/src/sgml/installation.sgml:      You need <productname>ZSTD</productname>, if you want to support
> doc/src/sgml/installation.sgml:         Build with <productname>ZSTD</productname> compression support.

I don't see any official sources calling it all-uppercase ZSTD.  In a
quick non-scientific survey, most seem to use Zstd or zstd.  The
non-abbreviated official name is Zstandard, but it's hard to find any
places using that spelling, and I don't think our docs are a place to
educate people on what the official name or pronunciation is.

I propose we standardize on <productname>Zstd</productname> everywhere.
Users can look it up if they're really interested.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

  15. Re: typos

    Amit Kapila <amit.kapila16@gmail.com> — 2022-04-20T03:49:16Z

    On Tue, Apr 19, 2022 at 4:35 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> Yeah, more invasive rewording seems called for.  I propose this:
>
>    For publications containing partitioned tables, the row filter for each
>    partition is taken from the published partitioned table if the
>    publication parameter <literal>publish_via_partition_root</literal> is true,
>    or from the partition itself if it is false (the default).
>
> I think we should also mention that this parameter affects row filters,
> in the <varlistentry> for the WITH clause.  Currently it has
>
>         <term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>
>         <listitem>
>          <para>
>           This parameter determines whether changes in a partitioned table (or
>           on its partitions) contained in the publication will be published
>           using the identity and schema of the partitioned table rather than
>           that of the individual partitions that are actually changed; the
>           latter is the default.  Enabling this allows the changes to be
>           replicated into a non-partitioned table or a partitioned table
>           consisting of a different set of partitions.
>          </para>
>
> I propose to add
>
>         <term><literal>publish_via_partition_root</literal> (<type>boolean</type>)</term>
>         <listitem>
>          <para>
>           This parameter determines whether changes in a partitioned table (or
>           on its partitions) contained in the publication will be published
>           using the identity and schema of the partitioned table rather than
>           that of the individual partitions that are actually changed; the
>           latter is the default.  Enabling this allows the changes to be
>           replicated into a non-partitioned table or a partitioned table
>           consisting of a different set of partitions.
>          </para>
>
>         <para>
>          This parameter also affects how row filters are chosen for partitions;
>          see below for details.
>         </para>
>

Your proposed changes look good to me but I think all these places
need to mention 'column list' as well because the behavior is the same
for it.

> More generally, I think we need to connect the WHERE keyword with "row
> filters" more explicitly.  Right now, the parameter reference says
>
>       If the optional <literal>WHERE</literal> clause is specified, rows for
>       which the <replaceable class="parameter">expression</replaceable>
>       evaluates to false or null will not be published. Note that parentheses
>       are required around the expression. It has no effect on
>       <literal>TRUNCATE</literal> commands.
>
> I propose to make it "If the optional WHERE clause is specified, it
> defines a <firstterm>row filter</firstterm> expression.  Rows for which
> the row filter expression evaluates to false ..."
>

Looks good to me.

-- 
With Regards,
Amit Kapila.

  16. Re: typos

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-04-20T12:01:37Z

    On 2022-Apr-20, Amit Kapila wrote:

> Your proposed changes look good to me but I think all these places
> need to mention 'column list' as well because the behavior is the same
> for it.

Hmm, you're right.  Added that, and changed the wording somewhat because
some things read awkwardly.  Here's the result in patch form.

Column lists seems not mentioned in logical-replication.sgml, either.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La verdad no siempre es bonita, pero el hambre de ella sí"

  17. Re: typos

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-04-20T21:32:08Z

    On 2022-Apr-19, Alvaro Herrera wrote:

> I propose we standardize on <productname>Zstd</productname> everywhere.
> Users can look it up if they're really interested.

So the attached.

There are other uses of <literal>zstd</literal>, but those are referring to the
executable program.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"No necesitamos banderas
 No reconocemos fronteras"                  (Jorge González)

  18. Re: typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-04-20T21:38:42Z

    On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:
> On 2022-Apr-19, Alvaro Herrera wrote:
> 
> > I propose we standardize on <productname>Zstd</productname> everywhere.
> > Users can look it up if they're really interested.
> 
> So the attached.
> 
> There are other uses of <literal>zstd</literal>, but those are referring to the
> executable program.

This one shouldn't be changed, or not like this?

> @@ -560,7 +560,7 @@ $ENV{PROVE_TESTS}='t/020*.pl t/010*.pl'
>      <varlistentry>
>       <term><varname>ZSTD</varname></term>
>       <listitem><para>
> -      Path to a <application>zstd</application> command. The default is
> +      Path to a <application>Zstd</application> command. The default is
>        <literal>zstd</literal>, which will search for a command by that
>        name in the configured <envar>PATH</envar>.
>       </para></listitem>

Maybe it should say s/a/the/, like:

-      Path to a <application>zstd</application> command. The default is
+      Path to the <application>zstd</application> command. The default is

  19. Re: typos

    Amit Kapila <amit.kapila16@gmail.com> — 2022-04-21T02:25:10Z

    On Wed, Apr 20, 2022 at 5:31 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2022-Apr-20, Amit Kapila wrote:
>
> > Your proposed changes look good to me but I think all these places
> > need to mention 'column list' as well because the behavior is the same
> > for it.
>
> Hmm, you're right.  Added that, and changed the wording somewhat because
> some things read awkwardly.  Here's the result in patch form.
>

LGTM.

-- 
With Regards,
Amit Kapila.

  20. Re: typos

    Michael Paquier <michael@paquier.xyz> — 2022-04-21T04:36:29Z

    On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:
> So the attached.
> 
> --- a/doc/src/sgml/install-windows.sgml
> +++ b/doc/src/sgml/install-windows.sgml
> @@ -307,9 +307,9 @@ $ENV{MSBFLAGS}="/m";
>      </varlistentry>
>  
>      <varlistentry>
> -     <term><productname>ZSTD</productname></term>
> +     <term><productname>Zstd</productname></term>
>       <listitem><para>
> -      Required for supporting <productname>ZSTD</productname> compression
> +      Required for supporting <productname>Zstd</productname> compression

Looking at the zstd project itself for reference or just wiki-sensei,
I don't think that this is correct:
https://github.com/facebook/zstd
https://en.wikipedia.org/wiki/Zstd

Their README uses "zstd" in lower-case, while "Zstd" (first letter
upper-case) is used at the beginning of a sentence.
--
Michael

  21. Re: typos

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-04-21T13:59:49Z

    On 21.04.22 06:36, Michael Paquier wrote:
> On Wed, Apr 20, 2022 at 11:32:08PM +0200, Alvaro Herrera wrote:
>> So the attached.
>>
>> --- a/doc/src/sgml/install-windows.sgml
>> +++ b/doc/src/sgml/install-windows.sgml
>> @@ -307,9 +307,9 @@ $ENV{MSBFLAGS}="/m";
>>       </varlistentry>
>>   
>>       <varlistentry>
>> -     <term><productname>ZSTD</productname></term>
>> +     <term><productname>Zstd</productname></term>
>>        <listitem><para>
>> -      Required for supporting <productname>ZSTD</productname> compression
>> +      Required for supporting <productname>Zstd</productname> compression
> 
> Looking at the zstd project itself for reference or just wiki-sensei,
> I don't think that this is correct:
> https://github.com/facebook/zstd
> https://en.wikipedia.org/wiki/Zstd
> 
> Their README uses "zstd" in lower-case, while "Zstd" (first letter
> upper-case) is used at the beginning of a sentence.

It is referred to as "Zstandard" at both of those places.  Maybe we 
should use that.  That is also easier to pronounce.

  22. Re: typos

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-04-21T17:16:54Z

    On 2022-Apr-21, Peter Eisentraut wrote:

> It is referred to as "Zstandard" at both of those places.  Maybe we should
> use that.  That is also easier to pronounce.

Yeah, I looked at other places (such as Yann Collet's blog) and I agree
that Zstandard seems to be the accepted spelling of the product.  Pushed
that way.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
Tom: There seems to be something broken here.
Teodor: I'm in sackcloth and ashes...  Fixed.
        http://archives.postgresql.org/message-id/482D1632.8010507@sigaev.ru

  23. Re: typos

    Justin Pryzby <pryzby@telsasoft.com> — 2022-05-11T02:03:34Z

    I found a bunch more typos; a couple from codespell, and several which are the
result of looking for previously-reported typos, like:

time git log origin --grep '[tT]ypo' --word-diff -U1 |grep -Eo '\[-[[:lower:]]+-\]' |sed 's/^\[-//; s/-\]$//' |sort -u |grep -Fxvwf /usr/share/dict/words >badwords.txt
time grep -rhoFwf badwords.txt doc |sort -u >not-badwords.txt
time grep -Fxvwf not-badwords.txt ./badwords.txt >./badwords.txt.new
time grep -rhoIFwf ./badwords.txt.new src --incl='*.[chly]' --incl='*.p[lm]' |sort |uniq -c |sort -nr |less

  24. Re: typos

    Michael Paquier <michael@paquier.xyz> — 2022-05-11T06:41:27Z

    On Tue, May 10, 2022 at 09:03:34PM -0500, Justin Pryzby wrote:
> I found a bunch more typos; a couple from codespell, and several which are the
> result of looking for previously-reported typos, like:

Thanks, applied 0002.

Regarding 0001, I don't really know which one of {AND,OR}ed or
{AND,OR}-ed is better.  Note that the code prefers the former, but
your patch changes the docs to use the latter.
--
Michael

  25. Re: typos

    Noah Misch <noah@leadboat.com> — 2022-07-05T07:51:39Z

    On Thu, Apr 14, 2022 at 08:56:22AM +1200, David Rowley wrote:
> 0007: Not pushed. No space after comment and closing */  pgindent
> fixed one of these but not the other 2.  I've not looked into why
> pgindent does 1 and not the other 2.

> -/* get operation priority  by its code*/
> +/* get operation priority by its code */

pgindent never touches comments that start in column zero.  (That's why many
column-0 comments are wrapped to widths other than the standard 78.)