non-string or non-string
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/functions-string.html Description: The second line in "Table 9.8. SQL String Functions and Operators" uses "non-string or non-string" as part of the example. I assume one of these should be "string".
Re: non-string or non-string
On 2020-May-17, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/functions-string.html > Description: > > The second line in "Table 9.8. SQL String Functions and Operators" uses > "non-string or non-string" as part of the example. I assume one of these > should be "string". No, it's not the example but the operator description, and what it says is "string || non-string or non-string || string" so it's trying to illustrate that there are two options: string || non-string non-string || string but maybe it's not super-clear about that. This is much clearer in the docs for Postgres 13, which has been heavily reformatted: https://www.postgresql.org/docs/devel/functions-string.html -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: non-string or non-string
PG Doc comments form writes: > The second line in "Table 9.8. SQL String Functions and Operators" uses > "non-string or non-string" as part of the example. I assume one of these > should be "string". It might look that way depending on how wide your browser window is... but the way it's supposed to be read is string || non-string or non-string || string The devel version of the docs forces the two cases to be on separate lines, which hopefully will stem the confusion. regards, tom lane
Re: non-string or non-string
> No, it's not the example but the operator description, and what it says > is > "string || non-string or non-string || string" > > so it's trying to illustrate that there are two options: > > string || non-string > non-string || string I see, that makes a lot more sense. > but maybe it's not super-clear about that. This is much clearer in the > docs for Postgres 13, which has been heavily reformatted: > https://www.postgresql.org/docs/devel/functions-string.html Oh wow, that's quite the change. I'm going to use the updated docs moving forward, it confused me at first, after years of visually parsing the previous format, but it's clearer once you understand the structure. Thanks, Bertrand
Re: Missing comma?
On Sat, May 16, 2020 at 09:38:46PM +0300, Marina Polyakova wrote: > I like if we can explain the situation in more detail. But IMO the phrase > "same as default" sounds as if we will try to find the primary index and use > it if the required index (with pg_index.indisreplident = true) does not > exist. What do you think of "(same as nothing if the index used got > dropped)"? It seems that in this case we have the same behaviour: > - we cannot update or delete rows from the table if the action is published > because this table does not have a "working" replica identity; > - we cannot apply updates or deletes on subscriber until we have a primary > key or the published relation has replica identity full. Yeah. I was testing that once again today and you are right. The publisher would just assume that there is nothing as there is in the changes nothing about the old row for a relation using a replident based on an index that got dropped, and this even if there is a primary key on the relation. So using "same as nothing" would be fine. (No need for logical replication to test that actually. You can just use one cluster with wal_level = logical and a slot with test_decoding to grab the same amount of information.) Would you like to send an updated patch? Note that as the release of beta1 is planned for this week, we have a grace period until the version is tagged on HEAD. -- Michael signature.asc Description: PGP signature
