Re: PG DOCS - logical replication filtering - Mailing list pgsql-hackers
From | Euler Taveira |
---|---|
Subject | Re: PG DOCS - logical replication filtering |
Date | |
Msg-id | 3cd8d622-6a26-4eaf-a5aa-ac78030e5f50@www.fastmail.com Whole thread Raw |
In response to | Re: PG DOCS - logical replication filtering (Peter Smith <smithpb2250@gmail.com>) |
Responses |
Re: PG DOCS - logical replication filtering
Re: PG DOCS - logical replication filtering |
List | pgsql-hackers |
On Tue, Apr 12, 2022, at 5:30 AM, Peter Smith wrote:
Not changed. Because in fact, I copied most of this sentence(including the uppercase, "operations", "and/or") from existingdocumentation [1]e.g. see "The tables added to a publication that publishes UPDATEand/or DELETE operations must ..."
Hmm. You are checking the Notes. I'm referring the the publish parameter. IMO
this sentence should use operations in lowercase letters too because even if
you create it with uppercase letters, Postgres will provide a lowercase word
when you dump it.
Yeah, I know the information is the same in the summary and in thetext. Personally, I find big slabs of technical text difficult todigest, so I'd have to spend 5 minutes of careful reading and drawingthe exact same summary on a piece of paper anyway just to visualizewhat the text says. The summary makes it easy to understand at aglance. But I have modified the summary in [v9] to remove the "case"and to add other column headings as suggested.
Isn't it better to use a table instead of synopsis?
Not changed. The readers of this docs page are all users who will befamiliar with the filter expressions, so I felt the "OR'ed together"part will be perfectly clear to the intended audience.
If you want to keep it, change it to "ORed". It is used in indices.sgml. Let's
keep the consistence.
But I did not understand your point about “If, for some reason,someone decided to change it, this section will contain obsoleteinformation”, because IIUC that will be equally true for both theexplanation and the output, so I did not understand why you say "psqloutput is fine, the explanation is not". It is the business of thisdocumentation to help the user to know how and where they can find therow filter information they may need to know.
You are describing a psql command here. My point is keep psql explanation in
the psql section. This section is to describe the row filter feature. If we
start describing features in other sections, we will have outdated information
when the referred feature is changed and someone fails to find all references.
I tend to concentrate detailed explanation in the feature section. If I have to
add links in other sections, I use "Seee Section 1.23 for details ...".
Not changed. The publisher and subscriber programlistings are alwaysseparated. If you are looking at the rendered HTML I think it is quiteclear that one is at the publisher and one is at the subscriber. OTOH,if we omitted creating the tables on the subscriber then I think thatreally would cause some confusion.
The difference is extra space. By default, the CSS does not include a border
for programlisting. That's why I complained about it. I noticed that the
website CSS includes it. However, the PDF will not include the border. I would
add a separate description for the subscriber just to be clear.
One last suggestion, you are using identifiers in uppercase letters but
"primary key" is in lowercase.
pgsql-hackers by date: