Example code bug: destination->data
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/15/xfunc-c.html
Description:
38.10.2. Base Types in C-Language Functions
In the last example of the section, this line appears:
memcpy(destination->data, buffer, 40);
For me, this gave the following error:
error: ‘text’ {aka ‘struct varlena’} has no member named ‘data’
After tracking down the struct definition, I got the example working with:
destination->vl_dat instead. I assume this is correct, and that the member
name changed somewhere along the way.
--
Ray Brinzer
Possibly Incorrect Data Return
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/tutorial-agg.html Description: Hello: I am working through the tutorial and the Doc page says the row count is 5 but my results show 0 records. Of course, I may be doing something wrong, too: jwjwj=# SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30) FROM weather GROUP BY city HAVING max(temp_lo) < 40; city | max | count -+-+--- Hayward | 37 | 0 (1 row)
Re: Example code bug: destination->data
PG Doc comments form writes:
> 38.10.2. Base Types in C-Language Functions
> In the last example of the section, this line appears:
> memcpy(destination->data, buffer, 40);
> For me, this gave the following error:
> error: ‘text’ {aka ‘struct varlena’} has no member named ‘data’
> After tracking down the struct definition, I got the example working with:
> destination->vl_dat instead. I assume this is correct, and that the member
> name changed somewhere along the way.
Hmm. It's correct by reference to the sample definition of struct
text just above ... but you're right that that has relatively little
to do with the definition we actually use nowadays.
However, referencing vl_dat[] isn't considered good style either
--- AFAICS there are exactly zero direct uses of that name.
The style actually used in the code is to rely on VARDATA() or
VARDATA_ANY(), as in the concat_text() example further down.
Maybe the best fix is to leave the example as it stands but add
a note that this is an oversimplified example?
regards, tom lane
Re: Possibly Incorrect Data Return
PG Doc comments form writes: > Hello: I am working through the tutorial and the Doc page says the row count > is 5 but my results show 0 records. Of course, I may be doing something > wrong, too: > jwjwj=# SELECT city, max(temp_lo), count(*) FILTER (WHERE temp_lo < 30) > FROM weather > GROUP BY city > HAVING max(temp_lo) < 40; > city | max | count > -+-+--- > Hayward | 37 | 0 > (1 row) No, you're right, given the sample data shown earlier then count = 0 is what you would get. Somebody injected this FILTER example without a lot of thought, it would appear, as not only does the output not match but it's completely disjointed from the flow of explanation (IMO anyway). This example originally introduced only HAVING, and trying to make it do double duty just confuses things. A fully separate example of FILTER would have served better. I'll go do something about that --- thanks for the report! regards, tom lane
Re: Usability ideas: text width and headers that are links
On Mon, Nov 7, 2022 at 1:41 AM Alvaro Herrera wrote: > On 2022-Oct-21, Niels Bom wrote: > > Setting a max-width on regular textual content is good for > > readability, which in turn increases accessibility. See this W3C a11y > > documentation (1) and an a11y page by the US government (2) for more > > detailed info. > > > > Using the CSS max-width property makes narrower sizes possible (for > > smaller screens) but sets an upper limit. The newer `ch` unit in CSS > > is a good-enough approximation of the average width of a character. > > I've seen 66ch as the "ideal" width for regular text. For the docs > > code examples need to have enough width too of course. But we can have > > those be wider than their containing element if need be. > > +1 for this idea. (I often open multiple windows just so that I end up > with the right width in the one containing text to read, as a substitute > for this.) For what it's worth, I've also often wished for a max-width on the docs. Another +1. 66ch ends up rather stark, though: I think we should go with something considerably wider.
