Re: typos - Mailing list pgsql-hackers

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/