Thread: There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"
There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"
From
PG Doc comments form
Date:
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/datatype-net-types.html Description: 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
Re: There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"
From
Tom Lane
Date:
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
Re: There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"
From
"David G. Johnston"
Date:
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.
Re: There is an invalid value for cidr type in the "Table 8.22. cidr Type Input Examples"
From
Tom Lane
Date:
"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