public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alvaro Herrera <[email protected]>
To: Justin Pryzby <[email protected]>
Cc: David Rowley <[email protected]>
Cc: [email protected]
Cc: Fabien COELHO <[email protected]>
Cc: Amit Kapila <[email protected]>
Subject: Re: typos
Date: Tue, 19 Apr 2022 13:05:23 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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/
view thread (5+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: typos
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox