Re: typos

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: typos
Date: 2022-04-19 11:05:23
Message-ID: 202204191105.uy6j3whgxbnh@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

In response to

  • Re: typos at 2022-04-14 00:33:01 from Justin Pryzby

Responses

  • Re: typos at 2022-04-20 03:49:16 from Amit Kapila
  • Re: typos at 2022-04-20 21:32:08 from Alvaro Herrera

Browse pgsql-hackers by date

  From Date Subject
Next Message André Hänsel 2022-04-19 11:25:21 Bad estimate with partial index
Previous Message Alvaro Herrera 2022-04-19 09:53:33 Re: Fix NULL pointer reference in _outPathTarget()