Re: `inet` docs suggestion and possible bug report
Sounds good. Thanks for researching this! On Tue, Apr 29, 2025, 4:37 PM Tom Lane wrote: > I wrote: > > Nathan Long writes: > >> At least in the case of `inet`, another reason is for accurate > comparison. > >> IPv4 and IPv6 both have shorthand textual representations; eg `127.1` = > >> `127.1.0.0`. Text storage would consider these unequal. > > > I'm not sure how much we want to press that point, because AFAICS > > the code we use does not have the same abbreviation rules you are > > expecting. Notably, it thinks '127.1' means 127.1.0.0. > > (We lifted this logic from BIND 20+ years ago, so while it might > > not entirely agree with practice elsewhere, it has a respectable > > pedigree and I'm hesitant to mess with it.) > > I spent a little while researching this. BIND stopped including the > relevant code at all sometime in the past 10 years, apparently feeling > that POSIX standardization means the libc versions of inet_pton() > behave sufficiently alike everywhere. You can still find copies > of their code at, eg, > > https://users.isc.org/~each/doxygen/bind9/inet__pton_8c-source.html > > and there are also versions in the NetBSD source tree and probably > elsewhere. As far as I can find, none of these will interpret '127.1' > as 127.0.0.1. Some will reject it (which is what the POSIX spec for > the function says to do) and some will interpret it as 127.1.0.0. > > Where 127.1 => 127.0.0.1 seems to come from is inet_addr (in POSIX) > and inet_aton (not in POSIX), which are legacy IPv4-only functions. > They say (quoting POSIX here): > > Values specified using IPv4 dotted decimal notation take one of > the following forms: > > a.b.c.d > When four parts are specified, each shall be interpreted as a > byte of data and assigned, from left to right, to the four > bytes of an Internet address. > > a.b.c > When a three-part address is specified, the last part shall be > interpreted as a 16-bit quantity and placed in the rightmost > two bytes of the network address. This makes the three-part > address format convenient for specifying Class B network > addresses as "128.net.host". > > a.b > When a two-part address is supplied, the last part shall be > interpreted as a 24-bit quantity and placed in the rightmost > three bytes of the network address. This makes the two-part > address format convenient for specifying Class A network > addresses as "net.host". > > a > When only one part is given, the value shall be stored > directly in the network address without any byte > rearrangement. > > All numbers supplied as parts in IPv4 dotted decimal notation may > be decimal, octal, or hexadecimal. > > Frankly, I don't think we want to support this. Classful network > addresses have gone the way of the dodo. And the fact that it'd be > inconsistent with our traditional interpretation for some non-error > cases such as '127.1/16'::inet is really problematic. > Moreover, the option to allow octal input is a true disaster, not > least because there is plenty of code out there that is willing to > print IPv4 addresses with zero-padded *decimal* byte values. > > So at this point I'm very unexcited about touching the behavior of > inet_in. Maybe in another universe it would have acted differently, > but we have too many years of history with the current behavior. > > I do take your point about the inet types helping to standardize > comparison behavior, but I think we should probably limit the text > to talking about IPv6 abbreviations. Maybe like > > these types offer input error checking and specialized > operators and functions (see ). > + They also simplify comparisons of inconsistently-written addresses, > + such as abbreviated and unabbreviated IPv6 addresses. > > > regards, tom lane >
29.2. Subscription
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/logical-replication-subscription.html Description: Hi, https://www.postgresql.org/docs/17/logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-EXAMPLES Firstly - a big thank you! As an Oracle DBA, new to PostgreSQL, and therefore learning all the time, every time I have reason to consult the PostgreSQL documentation, I'm hugely impressed with the amount, quality, clarity, and accessibility of the documentation provided. As a documentaion anorak myself, it brings a big smile to my face so, as I said, thank you! Today, I happened to be re-doing, and expanding on, labs on logical replication, covered on a recently-completed course. I browsed through the online documentation, (smiled), and started following the examples provided in "29.2.2. Examples: Set Up Logical Replication." Having created tables on publisher and subscriber, inserted data on the publisher, and created publication and subscription, I found my results to be the exact opposite of those indicated here - "Observe that initial table data is copied, regardless of the publish operation of the publication.". My subscriber tables t2 and t3 were emply (as though the (publish = 'truncate') rule had in fact been applied to the initial data). As a result, having inserted the second set of data, my tables now look like this: = = Publisher = postgres=# INSERT INTO t1 VALUES (4, 'four'), (5, 'five'), (6, 'six'); INSERT 0 3 postgres=# INSERT INTO t2 VALUES (4, 'D'), (5, 'E'), (6, 'F'); INSERT 0 3 postgres=# INSERT INTO t3 VALUES (4, 'iv'), (5, 'v'), (6, 'vi'); INSERT 0 3 postgres=# SELECT * FROM t1; a | b ---+--- 1 | one 2 | two 3 | three 4 | four 5 | five 6 | six (6 rows) postgres=# SELECT * FROM t2; c | d ---+--- 1 | A 2 | B 3 | C 4 | D 5 | E 6 | F (6 rows) postgres=# SELECT * FROM t3; e | f ---+- 1 | i 2 | ii 3 | iii 4 | iv 5 | v 6 | vi (6 rows) = = Subscriber = postgres=# SELECT * FROM t1; a | b ---+--- 1 | one 2 | two 3 | three 4 | four 5 | five 6 | six (6 rows) postgres=# SELECT * FROM t2; c | d ---+--- (0 rows) postgres=# SELECT * FROM t3; e | f ---+--- (0 rows) Have I misunderstood something, perhaps inadvertantly mis-configured some obscure parameter, or (please no!) is the documentation incorrect? Thanks in advance for any guidance you're able to offer. Regards, Jes
Re: 29.2. Subscription
On Wed, Apr 30, 2025 at 12:51 PM PG Doc comments form < nore...@postgresql.org> wrote: > > https://www.postgresql.org/docs/17/logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-EXAMPLES > > Have I misunderstood something, perhaps inadvertantly mis-configured some > obscure parameter, or (please no!) is the documentation incorrect? > > Testing the documented script against master-ish shows it works as described (I dislike the fact the example cannot just be copy-pasted in bulk/chunks but that is a different topic). You are going to need to show the exact scripts that reproduce the observed behavior. The only thing different from a stock installation is setting wal_level = logical but creating publications without making that change would simply fail. David J.
