There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"

PG Doc comments form <noreply@postgresql.org> writes:

On the page:
https://www.postgresql.org/docs/16/datatype-net-types.html#DATATYPE-CIDR
in the "Table 8.22. cidr Type Input Examples"
is invalid value for CIDR notation: 2001:4f8:3:ba:​2e0:81ff:fe22:d1f1/128

The value is correct as displayed:

=# select '2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128'::cidr;
cidr
--------------------------------------
2001:4f8:3:ba:2e0:81ff:fe22:d1f1/128
(1 row)

However, if you try to copy-and-paste it from the web page,
you do indeed get a syntax error, or at least I do using Safari.
The reason is that there's a zero-width space hiding in there:

<row>
<entry>2001:4f8:3:ba:&zwsp;2e0:81ff:fe22:d1f1/128</entry>
<entry>2001:4f8:3:ba:&zwsp;2e0:81ff:fe22:d1f1/128</entry>
<entry>2001:4f8:3:ba:&zwsp;2e0:81ff:fe22:d1f1/128</entry>
</row>

and apparently copy-and-paste converts that into something
that cidr_in doesn't like. It doesn't like regular space
there either, so that's not so surprising.

I believe the &zwsp; got put in there to provide a line-break
opportunity and thus remove overwidth-line warnings in the
PDF docs build. There are a fair number of other places where
we do the same thing, although perhaps they are less likely
to be something somebody would try to copy-and-paste.

On the whole I'm inclined to do nothing here; these docs have to
satisfy a number of requirements, and "every example should be
copy-and-pasteable" doesn't seem like a good constraint to add.
Another idea perhaps could be to remove enough digits from the
example that it doesn't cause overwidth warnings in the PDF ---
but I'm not sure that's feasible in a 3-column table. Or we
could just drop this one example.

regards, tom lane

On Mon, Aug 5, 2024 at 4:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

On the whole I'm inclined to do nothing here; these docs have to
satisfy a number of requirements, and "every example should be
copy-and-pasteable" doesn't seem like a good constraint to add.
Another idea perhaps could be to remove enough digits from the
example that it doesn't cause overwidth warnings in the PDF ---
but I'm not sure that's feasible in a 3-column table. Or we
could just drop this one example.

Another option, write:
"Same as input."
in the other two columns - so one doesn't have to look closely at some 30
characters of hex to prove to themselves the inputs and outputs are indeed
identical.

Would do it elsewhere for consistency - it also does make the case stand
out which I think is a plus and part of the point of the table.

David J.

"David G. Johnston" <david.g.johnston@gmail.com> writes:

Another option, write:
"Same as input."
in the other two columns - so one doesn't have to look closely at some 30
characters of hex to prove to themselves the inputs and outputs are indeed
identical.

Oh, I like that, if it makes the table narrow enough. Probably need
to set it in italics or something to make it obviously not-data.

Would do it elsewhere for consistency

Right, we'd have to do it in each entry of this table (that it
is correct for).

regards, tom lane